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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
