Dave Burns <tburns <at> hawaii.edu> writes:
One directory seems to cause a problem:
ls /MyBook/paleo_enso/solar_forcing
ls: reading directory /MyBook/paleo_enso/solar_forcing: Invalid or
incomplete multibyte or wide character
Typically this would mean a non-UTF8 filename but please see below.
Find apparently gives up entirely, returns nothing where I know
there
is something:
find /MyBook/paleo_enso/solar_forcing
/MyBook/paleo_enso/solar_forcing
Also, this appears in the log:
grep -i ntfs /var/log/messages
Mar 23 08:03:41 c ntfs-3g[3165]: Incomplete multi-sector transfer:
Input/output error
Mar 23 08:03:41 c ntfs-3g[3165]: Skipping unrepresentable filename
(inode 34473): Invalid or incomplete multibyte or wide character
Mar 23 08:03:43 c ntfs-3g[3165]: Incomplete multi-sector transfer:
Input/output error
Mar 23 08:03:43 c ntfs-3g[3165]: Skipping unrepresentable filename
(inode 34473): Invalid or incomplete multibyte or wide character
The "Incomplete multi-sector transfer" disk read error message means
corrupted disk sectors (NTFS specific media CRC). The most common
reason is hardware fault. Either permanent or temporary.
CHKDSK /F/R DRIVE: should find, mark, replace bad disk sectors if
it's permanent.
Due to some technical reason (online recovery, repair), NTFS-3G
ignores this disk read error and trust uppers layers to online
fix or report the error. Unfortunately this happens in a very
misleading way, as a filename corruption which can be misunderstood
as a filename characterset encoding problem.
I scheduled the misleading error message to be fixed in the next
NTFS-3G driver. The correct error message should
"ls: reading directory /MyBook/paleo_enso/solar_forcing: Input/Output
error". Details are at
http://ntfs-3g.org/support.html#ioerror
Googling all that leads me to a bug that was supposed to be fixed(?
I
think? bug is 'version 9', mine is ntfs-3g-2009.2.1-2):
https://bugzilla.redhat.com/show_bug.cgi?id=467629
No. Your problem is unique and related to a hardware problem.
Hardware problems are extremely common (and it will be even more
so with bigger rotating and SSD drives) but they manifest in an
extremely diverse way. Thankfully NTFS has many consistency checks
and data redundancy hereby online recovery is often possible.
The only workaround I can think of is somehow using the inode and
mv/renaming the bogus files. But I don't know how to use mv with only
an inode number (man page a bit terse).
Not the file but the filename in the directory index is corrupt.
CHKDSK /F /R DEVICE: should help.
Regards, Szaka
--
http://ntfs-3g.org