1. Summarise the issue (what were doing, what went wrong?)

Every time we push to our alpha repo with "darcs 2.9.5 (+153 patches)", 
we have started to get this failure message:

"darcs: /repo/filecache-tmp-3: rename: unsatisified constraints 
(Directory not empty)"

(The number used on the tmpdir varies). It used to work fine every time, 
but something change and now it fails every time. 

The result is that the patches *are* on the remote repo (which we are 
local-push to), but we have do a "revert -a" on the remote repo to get 
it in the right state. 

2. What behaviour were you expecting instead?

Perfection. 

3. What darcs version are you using? (Try: darcs --exact-version)

"darcs 2.9.5 (+153 patches)"

4. What operating system are you running?
  
Ubuntu Linux 12.04. 

I'm going to try an ssh-push and see if that net's me new diagnostics. 

To be clear: This could be a show-stopper for us upgrading beyond 2.8.0.

local push via ssh nets the same result:

Writing inventory
darcs: /home/sap/alphasite/filecache-tmp-4: rename: unsatisified 
constraints (Directory not empty)
Apply failed

###

Next I'll try disabling patch-index on the remote repo.

Given that you have reproduced it with local push via ssh, you could now 
try changing what the 'darcs' executable is to isolate whether the problem 
is with 2.9.5 on the "remote" end (the one executed for apply) or on the 
"local" end. I'm guessing it will be the darcs on the remote end.

I'll also note:

I'm getting the same failure behavior every time I try to oblit in the 
problem repo as well. 

I tried running this on the problem repo and trying to push again:

  darcs optimize --disable-patch -index

... but pushing still failed with the same error! This was rather 
frustrating, as the issue appears to be related to the patch index 
directory. It appears that is still being accessed and used while patch 
index is disabled. It's my understanding the feature should be 
thoroughly ignored with patch-index is disabled. 

Meanwhile, I think I've found the source of the problem. I'll do some 
further testing and get back to you.

Here's my finding of what happened:

We had recently added a new darcs developer, but put them in the wrong 
Unix group. They could push to the repo fine, but doing so changed the 
"group" of the files in _darcs/patches/patch_index

After this point, pushes by other developers to this repo would fail due 
to related permissions issues. Our "fix" was to corrupt the group being 
used for all files in that repo. 

The fix for darcs should be to be defensive about possible permissions 
issues related to patch index, and provide an error message that points 
users in the right direction. 

The current message references a directory: "/repo/filecache-tmp-3" and a 
message about a directory: "Directory not empty", but I suspect the 
directory that is "not empty" is really _darcs/patches/patch_index. I can 
see that the "filecache_tmp" directory is indeed full of files. 

The related issue is that it appears further testing should be done to 
confirm that --disable-patch-index is really working.  Test this 
combination:
- Enable patch index, so files are exist in _darcs/patches/patch_index
- make the files so that they are not writable
- run darcs optimize --disable-patch-index
- Attempt to push to this repo.

I would expect it to work since patch-index is (reportedly) successfully 
disabled, but in my case it did not.

Thanks for the diagnosis!

Mark, would you mind checking if the problem about --disable-patch-index not 
reporting failure is fixed from your point of view by patch995 (which is in 
screened now)?

If you're feeling in the mood for writing test scripts, it would be great to 
have one for that issue and another for the still unfixed thing about being 
defensive about ermissions in general :-)

I have a patch for testing that --disable-patch-index actually fails if 
permissions don't permit to succeed. 

I nominate that the remaining scope be moved to another ticket, so this 
portion can be considered resolved. 

The second piece, which might still be an open issue, is that pushing to 
a darcs repo with an unwritable patch index should provide a better 
error message.

As proposed here earlier, I'm narrowing the scope of this and consider it 
resolved. I'm shortly open a ticket for the remaining bit.