This is the mail archive of the
mailing list for the Cygwin project.
Re: Can't write any.files from vi
- From: luke dot kendall at cisra dot canon dot com dot au
- To: cygwin at cygwin dot com
- Cc: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>,"Larry Hall (RFK Partners, Inc)" <lhall at rfk dot com>
- Date: Fri, 6 Sep 2002 16:45:14 +1000 (EST)
- Subject: Re: Can't write any.files from vi
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?
> > 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?
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
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
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 '\\\.'
A H D:\home\luke\.profile
And in particular:
$ vi .Xresources # Verify that I can't write it.
$ attrib .Xresources
$ attrib -h .Xresources
$ attrib .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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html