Rob Walker wrote:
The output of the examination above shows me that "cp -a" doesn't
preserve Full Control for the owner on the copied file. Is this the
expected behavior under ntsec? If I use CYGWIN=nontsec, Full Control is
preserved.
Well cp is a POSIX program and it has no idea what Windows style NT ACLs
are. It preserves the Unix modes of the file, in other words it sees
0555 on the source file and 0555 on the destination file, so it's done
it's job as far as it's concerned. The problem of course is that there
is not a one to one mapping of Unix modes to NT ACLs, so there is more
than one way to express mode 0555.
With 'nontsec', Cygwin doesn't even bother setting any ACLs, so things
fall back to the default Windows way where the ACL is inherited from the
directory, which is the same way that things worked when you used a
Windows program to create the first copy of the file. So the two files
have identical ACLs not because of anything cp -a did or didn't do, but
because they were essentially both created in the same manner and both
inherited the default ACL of the containing directory.
Also, another thing to note is that Cygwin uses the backup privilege of
Administrator accounts to enable root-like unix semantics. On a nix
system if you are root you can do anything, regardless of permissions.
This is not so on Windows. If you've got a file with mode 555, meaning
there are no +w bits, then normal Windows tools won't be able to write
to it which is why you are getting the error.