[svlug] Files That Will Not Delete
Robert Hajime Lanning
lanning at lanning.cc
Sat Nov 1 08:01:40 PST 2014
On Nov 1, 2014, Scott DuBois <sdubois at linux.com> wrote:
>On 10/31/2014 05:27 PM, Rick Moen wrote:
>> As Michael Eager was suggesting, the problem you should be worrying
>> your inability to delete a file, but rather the filesystem read
>So to elaborate on my question a bit further for the list to better
>understand the scope, lets consider the separation of processes to
>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
>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
>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
>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"
>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
>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
>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
Did anyone look at the kernel log to see if it was a read or write error at the block level?
Problem with reformat, it's a shotgun. If it was a block level error, you just lost your reference to the bad block.
You might need to do a block scan to remap bad blocks.
King of the Potato People
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the svlug