On Saturday 28 Jun 2014 15:50:23 Peter Humphrey wrote:
> On Saturday 28 June 2014 09:15:47 Dale wrote:
> > > Alan McKinnon wrote:
> --->8
> 
> > >> But that's not your main problem. You got those filenames because the
> > >> source disk somehow has a problem and the names couldn't be read
> > >> properly. So junk was used instead.
> 
> I thought it was more like: the file lister didn't recognise those bytes as
> valid characters so it printed a question-mark for each of them. If it is
> so, it's no use Dale looking for files with question-marks in their names.
> 
> --->8
> 
> > It listed some files with a question mark in it but not the ones I am
> > looking for.  So, is it possible that since it couldn't read the file it
> > just skipped them?
> 
> 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.
> 
> > I used rsync to do the copy instead of cp.  Maybe that is it or
> > otherwise, I have a ton of directories to go diggin in to find them
> > since it isn't the one I thought it was.
> 
> 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.
-- 
Regards,
Mick