Under Linux, on the very same MacBook that I do some OS X testing with, "make
check" fails in hashed_inventory.sh with hashed repos:

Running hashed_inventory.sh ...                  FAILED!
Output from failed hashed_inventory.sh:

# We'd just use `diff -x _darcs -r' if -x was portable.
diffx () {
    { find $1 -type f; find $2 -type f; } |
      sed  -e '/.*\/_darcs\//d' -e 's;^[^/]*;;' | sort | uniq |
      {
        while read part; do
            diff -c $1$part $2$part
        done
      }
}

makepristine () {
    rm -rf pristine
    mkdir pristine
    for i in `$DARCS show files --no-files --no-pending`; do
        echo mkdir -p pristine/$i;
        mkdir -p pristine/$i;
    done
    for i in `$DARCS show files --no-directories --no-pending`; do
        echo $DARCS show contents $i ">" pristine/$i;
        $DARCS show contents $i > pristine/$i;
        cat pristine/$i;
    done
}

test $DARCS || DARCS=$PWD/../darcs

rm -rf temp1 temp2 temp3 temp4 temp5
mkdir temp1
cd temp1
$DARCS init --hashed
touch foo
$DARCS add foo
$DARCS rec -m t1 -a -A tester
Finished recording patch 't1'
echo 1 >> foo
$DARCS what -s | grep -v No\ changes
M ./foo +1
$DARCS what -l | grep -v No\ changes
M ./foo +1
$DARCS what -sl | grep -v No\ changes
M ./foo +1
makepristine
$DARCS show files --no-files --no-pending
mkdir -p pristine/.
$DARCS show files --no-directories --no-pending
/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/../darcs
show contents ./foo > pristine/./foo
cd ..

$DARCS get temp1 temp2
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.
cd temp2
$DARCS changes
Mon Mar 24 18:55:29 CET 2008  tester
  * t1
makepristine
$DARCS show files --no-files --no-pending
mkdir -p pristine/.
$DARCS show files --no-directories --no-pending
/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/../darcs
show contents ./foo > pristine/./foo
cd ..

$DARCS get --hashed temp1 temp3
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.
cd temp3
$DARCS changes
Mon Mar 24 18:55:29 CET 2008  tester
  * t1
cp _darcs/hashed_inventory inv
$DARCS optimize
Done optimizing!
diff -c inv _darcs/hashed_inventory
rm inv
makepristine
$DARCS show files --no-files --no-pending
mkdir -p pristine/.
$DARCS show files --no-directories --no-pending
/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/../darcs
show contents ./foo > pristine/./foo
cd ..
cat temp3/pristine/foo

diffx temp2 temp3
diff -rc temp1/pristine temp3/pristine
diff -rc temp2/pristine temp3/pristine

cd temp1
$DARCS record -a -A tester -m t2
Finished recording patch 't2'
$DARCS push ../temp2 -a
Finished applying...
Push successful.
$DARCS push ../temp3 -a
Hash failure in
/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp3
of hash 0000000086-b5100d9e939afaf4693896ca15f6307e2f1f22ed2ec256fac1ab3e0e90429d85

darcs failed:  Couldn't fetch
`0000000086-b5100d9e939afaf4693896ca15f6307e2f1f22ed2ec256fac1ab3e0e90429d85'
in subdir pristine.hashed from sources:

thisrepo:/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp3
repo:/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp1

Apply failed!

My filesystem is behaving a bit weird. Probably that's the cause.

On Mon, Mar 24, 2008 at 06:06:12PM -0000, Reinier Lamers wrote:
> Under Linux, on the very same MacBook that I do some OS X testing with, "make
> check" fails in hashed_inventory.sh with hashed repos:

What type of processor is this, and is it running in 64-bit or 32-bit mode?
Is there anything else unusual about its setup that might give a hint as to
what is going wrong? It's mostly surprising because all our linux buildbots
(plus my machine) pass the tests, so I suspect there's something unusual
about yor machine (and if it's running in 32-bit mode, that could be it,
although I'm not sure).

[cut]
> $DARCS push ../temp3 -a
> Hash failure in
> /mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp3
> of hash 0000000086-b5100d9e939afaf4693896ca15f6307e2f1f22ed2ec256fac1ab3e0e90429d85
> 
> darcs failed:  Couldn't fetch
> `0000000086-b5100d9e939afaf4693896ca15f6307e2f1f22ed2ec256fac1ab3e0e90429d85'
> in subdir pristine.hashed from sources:
> 
> thisrepo:/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp3
> repo:/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp1
> 
> Apply failed!

Could you look at the file

/mnt/osx/Users/reinier/Source/darcs-unstable/tests-shell-old-fashioned.dir/temp3/_darcs/pristine.hashed/0000000086-b5100d9e939afaf4693896ca15f6307e2f1f22ed2ec256fac1ab3e0e90429d85

and verify that its sha256sum is
b5100d9e939afaf4693896ca15f6307e2f1f22ed2ec256fac1ab3e0e90429d85 and that
its size is 86 bytes?

And that reminds me:  maybe the trouble is the filesystem, as this looks to
be an osx mount, from the path.  What's the filesystem type, and might it
have a pathname-length restriction? I recently increased the size of the
hash by quite a bit, going from sha128 to sha256, and at the same time
adding ten bytes of file-length (this used as a very fast check if a file
might be the right one, also to improve the timestamp checking by also
checking if the file length has changed).  Anyhow, it's possible that we're
now generating filenames that are too long for the FS.  I'm not sure what
we'll do if that's the case.  I could decrease the number of digits for the
file length.  Or we could use something other than hex for the hash, but
that'd make it hard to check manually.

Thanks for the bug report, and I look forward to hearing more about what
went wrong!

Oh, and I presume this is reproducible?

David

Sorry, I didn't read your second message until after applying.  Are you sure
this is a disk-error-related issue?

David

Well, certainty doesn't exist, but there were some files in the  
created test repo (which was on the OS X partition) that I couldn't  
remove from Linux. I fsck'ed the partition (it found and fixed some  
errors) and tried again, but the problem persisted. Even when I  
attempted to 'ls' those files as root, I got an error something like  
"cannot access file foo". I rebooted into OS X and from there I could  
delete the files just fine.

I will reboot to Linux and try from its native partition tonight  
(tonight CET = in about 5 hours).

Reinier

On Tue, Mar 25, 2008 at 03:01:50PM -0000, Reinier Lamers wrote:
> Well, certainty doesn't exist, but there were some files in the  
> created test repo (which was on the OS X partition) that I couldn't  
> remove from Linux. I fsck'ed the partition (it found and fixed some  
> errors) and tried again, but the problem persisted. Even when I  
> attempted to 'ls' those files as root, I got an error something like  
> "cannot access file foo". I rebooted into OS X and from there I could  
> delete the files just fine.

Yuck.  :(

> I will reboot to Linux and try from its native partition tonight  
> (tonight CET = in about 5 hours).

Thanks!

And could you check whether the explanation of filepath length might be the
issue? It'd be nice to know, so we could help other users who might run
into this.
-- 
David Roundy
Department of Physics
Oregon State University

The test passes on the same Linux installation, when I run it on the ReiserFS
partition that the Linux system itself is installed on. Even when I use a long
path name
(/home/reinier/Desktop/this/is/a/rather/long/path/name/to/trick/darcs/unstable).
So I'm changing this to wont-fix again.