This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: rename(2) using NTFS transactions on Vista/2008
According to Corinna Vinschen on 5/20/2008 4:53 AM:
cygwin-1.7.0-9 had problems with rename("file","link") returning a
spurious ENOENT.
It should. The problem was a wrong test for the R/O bit and the
desperate, but incorrect try to remove the bit from the destination
file in this special case.
Fixed in 1.7.0-11.
I also noticed today a behavior where 'cp -p old new' was setting the
system bit on the new file, as if by 'attrib +S new', but haven't had time
to look into it further.
Did the new file exist before the copy? Did it have the S bit set? If
so, then that's natural. The problem is that Windows since W2K
disallows to overwrite files which have the SYSTEM and/or HIDDEN bits
set, if you don't specify the same flags in the NtCreateFile call.
See fhandler_base::open for the comment describing that.
Here's a simple testcase - I haven't strace'd yet to see which syscall in
the cp -p path is causing the issue, but plain cp does not have the problem.
$ rm -f ?
$ touch a
$ cp a b
$ cp -p a c
$ for f in ? ; do attrib $f ; done
A C:\cygwin-2\tmp\a
A C:\cygwin-2\tmp\b
A S C:\cygwin-2\tmp\c
$ cp a b
$ cp -p a c
$ for f in ? ; do attrib $f ; done
A C:\cygwin-2\tmp\a
A C:\cygwin-2\tmp\b
A S C:\cygwin-2\tmp\c
$ cp -p a b
$ cp a c
$ for f in ? ; do attrib $f ; done
A C:\cygwin-2\tmp\a
A S C:\cygwin-2\tmp\b
A S C:\cygwin-2\tmp\c
1.7.0-12 wasn't on the mirrors yet, and I haven't had time to build my own
cygwin1.dll since your NFS changes yet, but those look promising for the
speedup of remote file access.
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net