Michael Schmitz wrote:
BTW, I have straced "tar -C /usr/bin -c ." and found out that
'getdents64()' returns those corrupted filenames:
You mean, you pipe the output of this to /dev/null and wait for error
messages?
yes
How many repetitions?
it doesn't matter. It's 99+% reproducible so it's OK to run it under
strace etc - it's always doing the same thing, i.e. failing with
corrupted "slabtop"->"slabt".
Doesn't throw an error right away for
me... not even with your kernel image used.
now that smells. A timing problem caused by different host speed? :-O
Can't reproduce this; I've upgraded all disk images to testing in the
meantime, though.
I can reproduce it with both sarge and etch disk images I uploaded to
web. But with sarge I had different filenames "corrupted". Maybe you
could try the etch.img I uploaded - if you don't mind downloading 143 MB
file. Perhaps it depends on the number of files in a directory or
something like that.
Petr
P.S. I'll retest the etch.img and "tar -C /usr/bin -c . >/dev/null" on
another, slightly faster (K7 2500+) host. I'd let you know if it behaved
differently.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
