"Tolerant IO" fix for issue 434 addresses some of the repository corruption
issues. However, there is still a critical case when root modifies a repository
(changing the _darcs/inventory file ownership to root) and later user_a tries to
push a patch to the repository. All of the changes will be applied, the pristine
tree will be modified, but the inventory file will not reflect the patch. 

A very simple fix would be to check that the inventory file and other necessary
files are writable before modifying the repository or the pristine directory --
this would save us much time here repairing our repositories by hand.

drusenko,

Thanks for the report. Can you tell us which version of darcs this happened with? 

To further help us resolve it, you could possibly contribute a test script which
reproduces the issue. (See the tests/ directory of the darcs repo for examples).
Also, if you could test with the latest "Darcs2", including trying the
"--hashed" and "--darcs-2" repo formats, that would also be helpful. Unofficial
binaries for this release are available on the DarcsTwo page on the wiki. 

Thanks!

    Mark

On Thu, Jan 24, 2008 at 12:46:48PM -0000, David Rusenko wrote:
> "Tolerant IO" fix for issue 434 addresses some of the repository corruption
> issues. However, there is still a critical case when root modifies a repository
> (changing the _darcs/inventory file ownership to root) and later user_a tries to
> push a patch to the repository. All of the changes will be applied, the pristine
> tree will be modified, but the inventory file will not reflect the patch. 

I'll point out that this corruption is not possible with the new --hashed-2
and --darcs-2 repository formats.  I also have a couple of questions.

Does darcs exit with an appropriate error messge in this case? It ought to
do so.

> A very simple fix would be to check that the inventory file and other necessary
> files are writable before modifying the repository or the pristine directory --
> this would save us much time here repairing our repositories by hand.

A simpler fix would be to avoid appending to the inventory in the first
place, then we wouldn't have this permissions problem, provided no
directories are created by root.
-- 
David Roundy
Department of Physics
Oregon State University

Yes, darcs exits with an appropriate error message ("Permission denied on
_darcs/inventory" or similar).

We will have to try out darcs2 when a stable version is released -- since we are
running it to manage our production repositories, we'll want to make sure things
are nice and stable before we throw it live.

And on another note, if it's an easy fix, it would be hugely valuable for us to
have a "writable" check on the inventory file for 1.0.10

> I'll point out that this corruption is not possible with the new --hashed-2
> and --darcs-2 repository formats.

I just sent a regression test called "repo_not_writable.pl" which confirms that
both the hashed-2 or darcs-2 formats do resist this kind of corruption and
return an appropriate "darcs failed" message. The regression test also confirmed
with the "old fashioned" repo format, the corruption does appear to happen,
returning a "permission denied" message, presumably too late. 

Marking as "resolved-in-unstable". 

drusenko: If you are concerned about using darcs-2 in production, you can browse
through the bug tracker for all the "resolved-in-unstable" bugs. My findings are
that Darcs2 has solved many important problems for darcs and introduced no new
critical issues. We also have a automated test suite which runs over 1,000 tests
on darcs, insuring that many aspects of it work as expected. 

I plan to deploy darcs-2 to production as soon after it is released as it feasible.

That it already prevented this corruption issue even before you filed the bug
report is just one of the benefits!

The following patch sent by Ben Franksen <benjamin.franksen@helmholtz-berlin.de> updated issue issue612 with
status=resolved;resolvedin=2.12.0 HEAD

* renamed no longer failing test for resolved issue612 
Ignore-this: 7e4ff18e9920278ff4795b272fcccf41