[svlug] Files That Will Not Delete

Scott DuBois sdubois at linux.com
Sat Nov 1 07:44:01 PST 2014


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.

-- 
Scott DuBois BSIT
President EBLUG
Freenode: Roguehorse




More information about the svlug mailing list