$ darcs --version  
2.4.3 (release)
$ darcs init                
$ echo foo > foo
$ darcs rec -la -m foo
Finished recording patch 'foo'
$ chmod a-w _darcs/index
$ darcs what
darcs: opening of '_darcs/index' failed: permission denied (Permission
denied)
$ 

whatsnew shouldn't need write access.

I agree.  What do you think, Petr?

Would it be easy for Darcs to know when it can afford not to write the 
index?

I recently stumbled over this issue at work. The darcsweb cgi script
cannot display any diffs if the web server has no write access to the
repo. I managed to work around this by making darcsweb use a copy of the
darcs binary with the setuid bit set, but this has obvious disadvantages.

The least we should do is to fall back to not using the index in case we
have no write access.

This manifests as a DarcsWeb CGI regression upgrading from Debian jessie
to stretch:

$ darcs diff --match "hash bc576ad6f30675cca83d1b75a75"

works fine without write access with Darcs 2.8.5, but fails with

darcs: _darcs/index: opening of '_darcs/index' failed: permission denied
(Permission denied)

under Darcs 2.12.4. Rather than flipping the setuid bit, I'm considering
building a darcs_ro binary, if I can identify the responsible source line...

Is the needs-reproduction status still valid? Reproduction should be
straightforward.

Thanks wferi, shifting the status accordingly.

I have pushed a partial fix that at least solves the whatsnew problem. (It is 
partial because e.g. 'darcs diff' still fails with an obscure error if _darcs 
is not writable.)

The patch is attached, incase you want to play with it. It will apply cleanly 
only to screened, I fear, because between 2.12 and today I have made lots of 
refactorings in Darcs.Repository.State where I applied the fix. You can try to 
backport it, the principle should (hopefully) become clear when you look at 
what the patch does.

... and here is the promised patch bundle.

Attachments

• resolve-issue1959_-catch-permission-errors-when-accessing-the-index.dpatch

See also Patch1738.

In the long run we should change the index code and the API in such a 
way that we can use the index read-only. With the current index API 
this is not possible because in the index we store only a single mmap 
pointer for reading and writing. The change would involve duplicating 
the pointer, one for reading the other for writing.

Forgot to mention the role the API plays here: it is designed so that 
readIndex merely sets up the mmap and stores the pointer in the index 
object. We then have to call updateIndex to get a usable Tree IO 
object out of it. I have no idea why it was designed in that way but 
this API clearly does not allow read-only access.

Fixing diff on a read-only repo involves more than not using the index.
We also need to use a temporary location to store the trees in hashed
format. This is currently done in the usual place i.e.
_darcs/pristine.hashed. We need to make a temporary copy of this
directory and use that. I am working on a patch...