From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5188 invoked by alias); 29 Nov 2011 15:43:01 -0000 Received: (qmail 5178 invoked by uid 22791); 29 Nov 2011 15:42:59 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_40,RP_MATCHES_RCVD,TW_RW X-Spam-Check-By: sourceware.org Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Nov 2011 15:42:40 +0000 Received: (qmail 47509 invoked by uid 13447); 29 Nov 2011 15:42:38 -0000 Received: from unknown (HELO [172.20.0.42]) ([71.210.201.156]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with SMTP for ; 29 Nov 2011 15:42:38 -0000 Message-ID: <4ED4FD6B.4030109@etr-usa.com> Date: Tue, 29 Nov 2011 15:51:00 -0000 From: Warren Young User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Cygwin-L Subject: Re: /cygdrive/c permission denied References: <201111290006.pAT06SJQ2879534@mail.pittstate.edu> In-Reply-To: <201111290006.pAT06SJQ2879534@mail.pittstate.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-11/txt/msg00445.txt.bz2 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. Windows Security™) 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: ???????? user::--- group::--- group:root:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- (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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple