This appears with darcs 2.4.4, HEAD (= 2.4.98.1 (+ 18 patches)) and 
branch-2.5 ( 2.4.98.2 (+ 2 patches) ):

$ darcs get http://repos.mornfall.net/hsbackup 
s
darcs failed:  Couldn't fetch `0000000046-
5066653559d4d6134b022d66a634a17fdcf8db35d28b447e581fec284afa4689'
in subdir pristine.hashed from sources:

thisrepo:/home/guillaume/repos/hsbackup
cache:/home/guillaume/.darcs/cache
repo:http://repos.mornfall.net/hsbackup

Then (using 2.4.98.1 + ...) if I go inside my local copy and do "darcs 
check", it says the repo is consistent.

But if I do "darcs obliterate" I have:

darcs: Codec.Compression.Zlib: premature end of compressed stream


The file 0000000046-
5066653559d4d6134b022d66a634a17fdcf8db35d28b447e581fec284afa4689 appears 
in several unrelated repositories  (do a web search). How come?

Hi,

sorry that was a permission fluke, possibly related to recent server 
movement (or not). Anyway, fixed.

The file is present in multiple repositories because it's the default 
Setup.hs for cabal:


import Distribution.Simple
main = defaultMain

That's it. You should be able to get and use the repo normally now.

Yours,
   Petr.

OK it does work now thanks.

But one remark: if "darcs check" says "repo is consistent" and the 
"darcs obliterate" crashes, isn't it the case that "darcs check" should 
have checked harder? Maybe there is a way to make "darcs check" detect 
that the file Setup.hs was missing?

gh <bugs@darcs.net> writes:
> But one remark: if "darcs check" says "repo is consistent" and the 
> "darcs obliterate" crashes, isn't it the case that "darcs check" should 
> have checked harder? Maybe there is a way to make "darcs check" detect 
> that the file Setup.hs was missing?

That's indeed interesting... if I remove a file from pristine.hashed
manually and then darcs check, it indeed complains...

Ok, I see: check is only consulting the pristine hashes, not the file
contents themselves. So even though it can't look into the hashed file
that's missing, it has its hash and concludes it's the right file (since
the hash matches).

It may be worth making the checking stricter (i.e. apart from checking
that hashes are OK, also check for each pristine file, that the hash
corresponds to the content of the file...).

Care to file a new issue for this? Feel free to quote freely.

Yours,
   Petr.

Done: http://bugs.darcs.net/issue1906