On 03/04/2011 11:12 AM, Peter Binney wrote: > When running "ls -l" the permissions field shows as "----------+".
Which means that the owner has no permissions, but that there are ACLs which allow others permissions. Not entirely unusual, given Windows' ability to create files with a different owner than the current user, while allowing the current user to access the file (typically when done to places like the desktop, and caused by inheritance ACLs present on the directory where the problematic file is being created in the first place). > Oddly, "ls -l" shows the correct permissions if the pathname uses the > windows drive letter syntax. eg: > > $ pwd > /cygdrive/c > $ ls -l tmp/plb.txt > ----------+ 1 ga2binn Domain Users 5527 Mar 3 13:54 tmp/plb.txt > $ ls -l c:/tmp/plb.txt > -rw-r--r-- 1 ga2binn Domain Users 5527 Mar 3 13:54 c:/tmp/plb.txt That's because using a dos-style path disregards ACL parsing, and fakes the permission bits instead. The + shows that ACLs are present, and 'getfacl tmp/plb.txt' will show you the difference between the owner and your permissions. > Similarly, TAR images have no permissions on the files contained. eg: > > $ pwd > /cygdrive/c/tmp > $ tar cf - plb.txt | tar vtf - > ---------- ga2binn/Domain Users 5527 2011-03-03 13:54 plb.txt Here, the problem is that tar doesn't preserve ACLs by default, so the original POSIX mode (000) is preserved while the ACLs are lost, resulting in an truly inaccessible file (note that there is no longer a + in the listing). > > Even more oddly, this behaviour (both LS and TAR) occurs on a new PC > that I am moving to. That's another big case where the user ids on the old pc do not correpsond to the user ids on the new pc; copying preserved the old user id, but gave ACL access to the new user, resulting in odd permissions. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
