Mick wrote:
> On Saturday 28 Jun 2014 15:50:23 Peter Humphrey wrote:
>> It may not be true that it couldn't read the files; it just couldn't
>> translate their names into text characters. The names are not held in
>> the files whose names they are but somewhere in the inode structure.
>> Someone with better knowledge of this (i.e.any at all) will have to
>> explain what goes wrong if bytes on the disk adjacent to the file
>> names get damaged along with the names. Do you know any characters in
>> those dodgy names, Dale? If so, you may be able to use /usr/bin/find
>> like so (hoping this isn't a grandma's egg - apologies if it is):
>> find /path-to-files -iname \*known-part-of-name\* {} +
> It could have something to do with the character set of the
> terminal/application Vs the character set that the original file was created
> as. If you have UTF8 set as your default character encoding, you should
> hopefully be OK. If it shows ? in the name and 0 bytes size, it is likely a
> corrupt file.
>
> You can also try ddrescue with --input-position=<bytes> and
> --max-size=<bytes>
> to retrieve just the borked part of the disk.
Well, I was planing to just find them and delete them. If I could play
them and they work fine then I might save them but I figure they are
likely messed up in some way.
I have already zeroed out the stuff on the old drive that was going
out. That data is gone. If rsync didn't copy the files over, that is
cool. I'll go figure out what was missed and see if I can find new
copies. I only saw a chunk that looked like maybe 4 or 5 scrolling by.
Given the amount of data, I'd say it was well under a 1% loss. Maybe
not even 0.1% loss.
Learned to use the \ to search tho. Let's see if I remember that for
next time. lol
Dale
:-) :-)
