I'll be 'sending' a test to bugs directory shortly which illustrates the
following weakness of darcs: 

darcs "get" may fail with a permissions error even when the current directory
has sufficient permissions, and the remote directory has sufficient permissions,
as well, but a parent directory of the current repo has restrictive permissions. 

This is the case on some web-server setups where "/home" has restrictive
permissions, but people may run darcs from "/home/user/www". 

By using "strace", I can see that the failure point is when "chdir" is called
with the full path of the current directory. An example failure message looks
like this:

darcs: /home/mark/Haskell/darcs-unstable-hashed/bugs/tmp_restrictive/liberal:
setCurrentDirectory: permission denied (Permission denied)

It seems the fix would have to involve avoiding the "chdir" call to the full
path of the current repo. 

The bug is triggered in darcs 1.0.9 and a current build of Darcs2.

I'm skeptical of this bug.  Is it really not a broken system if we cannot chdir
into the repository directory? It's possible to fix this by only using relative
paths, but the reason we preferentially use absolute paths is because the use of
relative paths tends to be fragile, in the sense that they can easily lead to
bugs when small changes are made to the code.

A related question:  does situation invalidate *all* uses of absolute paths, or
only for certain operations like chdir? The only even moderately robust solution
I can imagine would be to replace all uses of setCurrentDirectory (and perhaps
all other FS access routines?) with one that checks the current directory and
computes from it a relative path to the absolute path we want to access.  It
sounds very fragile, and I'd really prefer not to take this approach.

So my leaning for this scenario would be to instruct users to run darcs in a
directory they have permissions to access with an absolute path.

I think your skepticism is well founded.   I think the situation is 
reasonable. Our server is a fairly stock cPanel setup with restrictive 
permissions on /home:

$ ls -lthd /home
drwx--x--x  61 root  wheel   1.5K Jan 18 14:47 /home

However, these operations still succeed for me:

cd /home/whereiam/www

 perl -MCwd -e  'chdir "/home/shopdons/www/store"; print cwd();';

I can also "cd" to /tmp and "cd" back.

Is this possible a Haskell bug? or maybe darcs is just executing an 
unnecessary command on a parent directory. It might be useful for 
someone else to review the test script that triggers it, and perhaps 
review the "strace" output of the failure point.

  Mark

Okay, part of this trouble is that the test script sets permissions to 0000,
which is more restrictive than what you describe as reasonable restrictive
permissions on /home (which allow execute, but not read).

I think this is a test-script bug.  It seems that if I set the permissions to
0111 on the superdir, the test passes.  Any less permissions than that, and I
don't think darcs can be expected to function properly.

David

Assigning to myself as test-script cleanup issue.

David beat me to the test-cleanup work. (Thanks!). I'm going to consider this
"resolved" for now, since we now lack a test case which triggers an unresolved
problem.