Corinna Vinschen writes: > In that case, the problem probably occurs because userB has no > permissions to read the file permissions. Cygwin's chmod creates a > POSIX compatible ACL, which adds READ_CONTROL permissions for everyone.
That seems to be the case here and would seem to explain it - thanks! BTW, it seems that chmod also adds FILE_READ_ATTRIBUTES though READ_CONTROL is all that was needed to solve my problem. Also, for the record, it seems that 'cp -a' does similar except it also *deletes* the SYSTEM ACL attributes of DELETE, WRITE_DAC and WRITE_OWNER. It's not intuitively obvious to me why 'cp -a' would degrade permissions... That being said is there (or should there) be a flag to 'cp' that will strictly preserve 'all' ACL attributes in a similar way to how Linux has the -Z flag to preserve SELinux context? (cp -r --preserve=all doesn't do so) I had always (mistakenly) assumed that 'cp -a' would do a "pristine" job of copying -- it would be nice to have a cygwin tool that would be pristine that way without having to go to Windows tools. I apologize for all these maybe newbie-like questions but I am still used to *nix rwx permissions and in this case even getfacl didn't help. I needed to go to my new "friend" subinacl to see what you were saying - wasn't obvious to me at least. -- View this message in context: http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26377078.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple