rename(2) using NTFS transactions on Vista/2008

[Eric Blake]

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