[svlug] Files That Will Not Delete

Michael Eager eager at eagercon.com
Sat Nov 1 10:08:27 PST 2014

On 11/01/14 08:44, Scott DuBois wrote:
> On 10/31/2014 05:27 PM, Rick Moen wrote:
>> As Michael Eager was suggesting, the problem you should be worrying is not
>> your inability to delete a file, but rather the filesystem read error.
> Good point.
> So to elaborate on my question a bit further for the list to better
> understand the scope, lets consider the separation of processes to occur.
> For some reason there is a file (actually an empty directory from the
> looks of it) that is stored on an ntfs formatted drive that in turn is
> handled by the ntfs-3g driver that will not respond to the rm command
> even invoking the -f option. These bits are at the end of a long string
> of a dir hierarchy. Moving to the lowest point of the dir branch and
> attempting the rm -rf command there results in the same error. The
> result being something broken in the driver's ability to effectively
> deal with the bit structure (of some type) in an ntfs system through the
> entire branch all the way to the mount point. However, the cp command
> was able to be correctly executed by the ntfs-3g driver thus allowing
> the saving of all relevant data associated to the branch to a ext4 file
> system.
> The inability for the rm command to effectively execute against the
> aforementioned branch caused questioning in any potential errors that
> may occur with the formatting of the drive from an ntfs system to an
> ext4 system. Knowing full well that all data had been successfully
> copied from one file system to another presented the opportunity to
> simply format over the ntfs system and the problematic branch in
> question as the branch was now deemed sacrificial.
> The driver that handles drive formatting was able to both format the
> entire drive as well as remove all remnant data left on that drive
> without error. Different driver, different process; correct?
> After reformatting the drive to a more "acceptable" file system, the mv
> command was executed on said branch to move it back to it's original
> mount point position. After which, the rm command was able to execute
> effectively without need or concern for the -f option.
> Proposed answer to original question (answer sought);
> Remember, you are dealing with a file system that is using, in a sense,
> a "patch" driver to try and get Linux and Microsoft to talk to each
> other. Think of it as a "translator" and sometimes things get screwed up
> in translation. Since you're going to be formatting this drive anyway,
> if you can copy your data over to a safe place don't worry too much
> about deleting it as reformatting is going to wipe it out. The odds are
> good the problem will be gone when you put that data back on a Linux
> type file system. If you can't copy the data either? Then we'll have to
> figure something out to be able to save that data before you "toast" it.
> Conclusion:
> Using a native Linux file system on external drives is much more
> reliable than trying to hack a non-native file system. Non-native
> systems are prone to errors and erratic behaviour and should be used
> with caution.
> Hypothesis:
> In a case where the ntfs-3g driver is having difficulty correctly
> executing the rm command on any ntfs interfaced file system sector or
> block, can the sector and block in question be isolated and formatted
> over applying a different method to achieve the same goal?
> Layman (non techie) desription:
> You cut your finger, it's bleeding so you aptly apply a band-aid. The
> cheap band-aids keep falling off and now you have a mess. What we're
> going to do is teach you how to apply high-tech laser surgery on your
> finger to cauterize the wound and stop the bleeding. Aka- we're going to
> show you how you can isolate that little spot on your drive where that
> data resides and kill it by formatting over it saving everything else
> around it.

Most of this is not really based on evidence.  If your finger is bleeding,
the problem isn't the adhesive in the band aid, but the cut.

1) You received an input/output failure while reading the disk.
    This doesn't have anything to do with whether you formatted the
    disk with NTFS/EXT4/other.  It's a hardware failure.

2) Formatting a disk does not write over existing data and will not
    identify or repair bad blocks.

3) The ntfs-3g is no more a translator than any other file system
    driver, such as ext4.  Virtual File System (VFS) is mapped to
    a specific disk representation in each case.  No amount of "getting
    confused in translation" is going to cause a hardware error.

4) Linux file systems are not more reliable than other file systems on
    hardware with read failures.  (At least, not enough to matter.)

5) It is incorrect to say "sector and block in question [can] be isolated
    and formatted over applying a different method".  File systems are
    data structures over a device, partition, or image, not applied on
    sector basis.

The problem is the hardware error.  Whatever you see after that is
consequent, not cause.

Run badblocks.

Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

More information about the svlug mailing list