CYGWIN=ntsec, "cp -a", and NT acls

Rob Walker
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
>> 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.

[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:
Problem reports:

More information about the Cygwin mailing list