Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 6 Sep 2002 16:45:14 +1000 (EST) From: luke DOT kendall AT cisra DOT canon DOT com DOT au Subject: Re: Can't write any.files from vi To: cygwin AT cygwin DOT com Cc: Igor Pechtchanski , "Larry Hall (RFK Partners, Inc)" In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: <20020906064505.7B4B45AAA@ivory.research.canon.com.au> I've found what was causing it; might be a Cygwin error. On 5 Sep, Igor Pechtchanski responded to Larry: > > I pulled this from your previous email: > > > > $ grep luke /etc/passwd > > luke:unused_by_nt/2000/xp:11021:10513:Luke Kendall,U-CISRA\luke,S-1-5-21-5706737 > > -76180391-208020174-1021:/home/luke:/bin/bash > > lukep:unused_by_nt/2000/xp:12898:10513:Luke Paton,U-CISRA\lukep,S-1-5-21-5706737 > > -76180391-208020174-2898:/home/lukep:/bin/bash > > $ ls -aln ~/.profile > > -rwxr-xr-x 1 11021 10513 4327 Aug 30 10:40 /home/luke/.profile > > > > > > Your uid (11021) and SID (S-1-5-21--76180391-208020174-1021) don't match. > > Are you sure this was generated by mkpasswd? Absolutely. > > You'll want to double check > > this and the difference in ownership and permissions between the files that > > vi is working with and those (like .profile) that it's not. I expect you'll > > see a difference there. There are no visible differences, except to vi. > > It's worth keeping in mind as well that the user > > your trying to be in this case is a domain user. While this isn't a no-no, > > it does come with some extra potential "gotchas" which I alluded to above > > and which are covered in the email archives. I can search through the archive - any suggestion of topics I should search by? I don't suppose there's anything in the FAQ or User Guide that I could read? Not logging into the domain is not an option, since I would then be unable to access anything on the network. We'd have to drop Cygwin if the resolution was to not login to the domain, I think. > But start with these checks > > and make sure something here doesn't signal the problem. > > Actually, the mismatching ids are fine - this is what mkpasswd generates > for domain users. This might, however, be the reason why this is > failing... Is your home directory on a network drive, by any chance? > I've had some permission troubles with samba drives and cygwin... No, it's a local hard disc that's FAT32. > What's the output of 'id' for you, by the way? > Igor It looks fine to me: $ vi .profile # Check that I still can't write .profile from vi $ ls -l .profile .xinitrc -rwxr-xr-x 1 luke Domain U 4327 Aug 30 10:40 .profile -rwxr-xr-x 1 luke Domain U 1618 Sep 6 12:13 .xinitrc $ id uid=11021(luke) gid=10513(Domain Users) groups=10513(Domain Users) $ ls -anl .profile .xinitrc -rwxr-xr-x 1 11021 10513 4327 Aug 30 10:40 .profile -rwxr-xr-x 1 11021 10513 1618 Sep 6 12:13 .xinitrc $ grep luke /etc/passwd luke:unused_by_nt/2000/xp:11021:10513:Luke Kendall,U-CISRA\luke,S-1-5-21-5706737 -76180391-208020174-1021:/home/luke:/bin/bash Ah, I've resolved it. Behold: $ ls -d .* . .bash_profile.old .kshrc .profile~ .viminfo .. .cvspass .profile .rhosts .vtclrc .Xresources .epa .profile.bash .sh_history .xinitrc .bash_history .exrc .profile.mks .ssh $ attrib | grep '\\\.' H D:\home\luke\.bash_history H D:\home\luke\.bash_profile.old H D:\home\luke\.cvspass H D:\home\luke\.epa H D:\home\luke\.exrc H D:\home\luke\.kshrc A H D:\home\luke\.profile H D:\home\luke\.profile.bash H D:\home\luke\.profile.mks H D:\home\luke\.profile~ H D:\home\luke\.rhosts H D:\home\luke\.sh_history H D:\home\luke\.viminfo H D:\home\luke\.vtclrc H D:\home\luke\.Xresources D:\home\luke\.xinitrc And in particular: $ vi .Xresources # Verify that I can't write it. $ attrib .Xresources H D:\home\luke\.Xresources $ attrib -h .Xresources $ attrib .Xresources D:\home\luke\.Xresources $ vi .Xresources # Check if I can now write it? Yes! Hidden files are meant to have the same semantics as "." files in Unix, I thought? If so, then I think it's an error that vi is considering them to be unwriteable. The reason for marking such files as hidden is the same as in Unix - to prevent accidental fiddling. An interesting question is, why does it seem to be only vi (vim) that exhibits this behaviour? It's vim 6.1, BTW. luke -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/