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