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