On Wed, May 14, 2008 at 08:53:41AM +0100, Simon Peyton-Jones wrote:
> | I also haven't been able to reproduce your bug, Simon. From the page
> | that Eric quoted, I'd guess that what we're seeing is
> | corruption-in-transit of a patch that we're pulling.
>
> That'd be surprising, because it *also* happens if I pull from a local
> repo of the HEAD, which itself seems to be working fine. (Maybe it's
> illusory that it's working fine.)
Hmmm. Yes, that does seem to eliminate the possibility of this being a
transport issue, which only makes it more puzzling. You aren't running out
of disk space, are you? (To ask the obvious...)
Just to be clear: does darcs check pass on the local HEAD repo that you get
the error when pulling from?
> | You've mentioned that this is darcs 1.0.9 on Windows. Do you know whether this
> | darcs was compiled with libcurl? All I can think is that maybe the bug is
> | library-related... so if you're using a transport method other than libcurl
> | (e.g. straight wget or curl) that would be interesting.
>
> I'm afraid I don't know -- I just took the binary download from the darcs
> site, so it depends how you built it.
>
> Meanwhile, I can probably work around this, so don't worry about fixing.
> I though you should know about it, though, because it's an obscure
> message that might leave someone else totally stuck.
It'd be nice to be able to reproduce this, though, so we could know that
it's fixed. I can't reproduce the problem with either the stock debian
darcs 1.0.9rc1 or with darcs 2.0.0 (+ 212 patches). :(
Could you perhaps try the same test with a darcs 2 (either compiled by
Simon M. or a precompiled binary from the wiki)? If you can't reproduce it
with darcs 2, I'll be less concerned. As it is, I'm worried that this may
be a windows-specific bug.
Does windows have something like the open file-descriptor limit that posix
systems have? If so, do you have any idea how to track that kind of trouble
down? At this point I'm just brainstorming what could be going wrong...
David |
