

Other format: [Raw text]

Re: /cygdrive/c permission denied

On 11/28/2011 5:06 PM, Mike Brennan wrote:

When I did "cd /cygdrive; ls -l" I got:

drwx------+ 1 ???????? ???????? 0 Nov 28 17:03 c

I don't think the ???????? is an error. I see much the same thing here, and I have full read/write access to C:\ via the Cygwin shell.

The only serious difference I see here is that I get "d---------+", so going by just that, I shouldn't even be able to cd into it! C:\ gets treated differently by Windows, probably for backwards compatibility with DOS or something. I'm guessing that this prevents Cygwin from faking POSIX permission semantics for that directory.

(Don't believe C:\ is special? Try creating a subdirectory in C:\ while UAC is enabled and you're logged in as an Admin. No UAC dim-out as you'd expect when WRITING TO THE FRIGGIN' ROOT DIRECTORY, if the UAC hype had anything to do with reality. Also no complaints when other programs write to the directory you just created on your behalf, unlike what happens if you try the same thing in, say, c:\PROGRA~1. <rolleyes>Windows Security&trade;</rolleyes>)

I'm assuming your cpio -p command overwrote the C:\ ACL with that of the top level directory of whatever you were copying. You may be able to fix it with setfacl. Here's what getfacl says here:

$ getfacl /c
# file: /c
# owner: ????????
# group: ????????

(Yes, I have cygdrive mounted on / here. I'm an evil, bad man. I don't think that explains anything, though.)

How you use setfacl to apply any diffs you need there is an exercise left to the reader. :)

By the way, if mirroring permissions is what you're after, I'm not sure cpio -p is the right thing unless you're copying a directory that historically has been managed only via programs built for Cygwin. I dunno, maybe Cygwin's cpio knows all about Windows ACLs and such, and doesn't just go by the faked POSIX permissions it gets from stat(2). I do know that such problems plagued Mac OS X for quite a while, and the impedance mismatch is much smaller between HFS+ and POSIX filesystem semantics than between NTFS and POSIX. I suggest using robocopy instead. I tend not to prefer native tools, but it'll likely give better results in this case.

Problem reports:
Unsubscribe info:
