CYGWIN=ntsec, "cp -a", and NT acls
Sat Dec 6 04:36:00 GMT 2008
Brian Dessent wrote:
> 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
> 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.
[RGW] This differs from my experience. Many Windows tools are able to
(built to?) twiddle +R and overwrite. They do not seem to be able to
handle when the ACLs deny them permission, though.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin