Re: /cygdrive permissions problem [failing duplicity backup]

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar 19 10:35, Jan-Aage Frydenb?-Bruvoll wrote:
> Dear all,
> 
> I am trying to get duplicity (backup) working, and everything seems
> ok apart from the fact that duplicity seems not to be able to see
> anything underneath /cygdrive.
> 
> Looking at the permissions on /cygdrive, things seem a little bit odd:
> 
> Fri Mar 19 10:29:56 jan@aeolus:/
> $ ls -ld /cygdrive/
> d--x--x--x 5 jan Administrators 0 2006-12-01 00:00 /cygdrive/

Thanks for the hint.  I fixed that in CVS so that the permissions
are r-xr-xr-x (0555).  Cygwin 1.5 had these permissions right and
it looks like an oversight when changing the cygdrive fstat method.

> However, I have no problems accessing the files underneath /cygdrive
> myself, and getfacl seems to disagree:

The permissions of the underlying directory are not reflected in
the fstat API.  We're pretending the cygdrive directory has fixed
0555 permissions because it's a virtual directory.  You could
remove the actual directory and cygdrive would still exist.

> Fri Mar 19 10:30:03 jan@aeolus:/
> $ getfacl.exe  /cygdrive
> # file: /cygdrive
> # owner: jan
> # group: Administrators
> user::rwx
> group::r-x
> other:r-x
> mask:rwx

Huh?  How did you do that?  The normal way how the ACL is printed is by
noticing that the virtual cygdrive directory does not support ACLs, so
fstat is called to fill the aclbuf_t structure.  Consequentially, if I
do the above I see (using the unfixed DLL):

  $ getfacl.exe  /cygdrive
  # file: /cygdrive
  # owner: corinna
  # group: vinschen
  user::--x
  group::--x
  other:--x
  mask:rwx

So the ACL is usually faked, just like the fstat permissions.  The
only way to get your above result is to rename the cygdrive prefix
and *then* to call `getfacl /cygdrive'.

> cygcheck and other Cygwin and Windows tools report of no problems
> that I can see. I cannot remember experiencing any other problems
> that I would attribute to any permissions issues on /cygdrive.
> 
> I have been googling high and low to no avail - I hope I haven't
> accidentally overlooked the solution to this problem. If so, if you
> could be so kind as to point me in the right direction, that would
> be highly appreciated.

That could happen if a tool checks for permissions and refuses to call
a function based on the permission settings.  Most of the time it's
easier to call the function and just choke if it returns an error.
Anyway, the simple patch to return read permissions on /cygdrive
might fix this for you.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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