On Tue, 08 Jan 2002 10:09:14 -0600, Steve Lord wrote:
>> You mean I should destroy this filesystem, re-create a fresh one, and start
>> the whole copy process again until it finishes without a filesystem
>> Of course I can't guarantee that the conditions will be the same as with
>> case you're referring to.
>That's what I was thinking, but maybe not, lets look at the names
It's not a problem at all to destroy the filesystem, but of course then it's
gone and I can't do any further inspections.
>> >I presume the name is a legitimate one from the source tree.
>> No -- it's not!! I just noticed that the CORRECT name would have been
>> "069746IM.drw" -- it's a Micrografx Designer file, thus the extension
>It means that the thing which is corrupted is the name itself, the hash
>value in the directory is the correct one for the name you supplied.
Yes, of course, but my question should have read "How could that happen?"
>So somehow a single character in the name got sat on, this is starting
>to get more interesting.
>If you look back through the old filenames in previous instances of
>this, are any of them incorrect too?
Yes, they are!!
ls: ./daten/software/win 2000/Standard Fonts/.AppleDouble/M
such file or directory
Here a line-feed has been introduced instead of a "T," the correct version
would have been:
ls: ./daten/software/win 2000/Standard Fonts/.AppleDouble/MTCORSVA.TTF
Another broken filename:
The correct filename would have been (notice the changed extension):
Ok, back to you...
Verkaufe Original-BMW-Raeder: L I N U X .~.
http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\
of a GNU /( )\