Discussion in 'backup, imaging & disk mgmt' started by Keatah, Oct 7, 2019.
Does anyone know of a program that will wipe all cluster tips (for all existing files) on a drive?
You wanna keep the DATA and just wipe out the cluster tips or clean that drive completely... or something else, maybe
Keep the data. It's a working system. Just want to hit the slack space between end-of-file and the cluster boundary.
I should also add it's WinXP rig, and tried ERASER, but it's not compiled for a win32 system.
ERASER wouldn't work for you anyway... it only has the option to erase Cluster Tips when sanitizing the entire file. I have never come across a tool that erases LIVE Cluster Tips (tips only on LIVE files).
An issue that needs to be dealt with while trying to do this is the Cluster Tip to be cleaned is not always at the end of the file... there can be unused tips within the file, especially if the file has been edited previously.
What if the file is defragged and all contiguous? Any tip would then be a result of the editing program not making a clean file. Right?
The term "clean file" is nebulous at best...
Most editing programs will reconstruct the file in new space (TEMP files) before it closes the file, saves the edit and renames the TEMP to the FileName. Think about this... your previous file now lays in the noise (unused space) with no MetaData to refer to it... just laying around now in the free space. Even with some sort of SECURE ERASE of the newly created file, the original one is still laying around somewhere so a FREE SPACE wipe would be required to rid your System of the original unedited file. Some secure wiping software can rid you of these left over file copies when the new one is created, but none that I know of will clean LIVE Cluster Tips.
Not all programs that edit do this either... some add file pieces into the middle of the file, with these pieces having their own Cluster Tips (along with the cluster at the end)... databases do this a lot. Now you have tips in the middle of the file and at the end. A defrag does not operate on file content, it operates on all the Clusters within the file. If an edited file (with new internal, fragmented clusters) is defragged, the Clusters are indeed placed back together (defragged) but they are full clusters and now they are lined back up with possible unused Cluster Tips in the middle of the file still.
I get the impression that you might be worried about a SECURITY issue... I can't think of any other reason to try and do this. So far, baddies have attacked "freespace" within partitions, but the most successful ones have attacked "unallocated" space on the hard drives themselves rather than "freespace" on allocated volumes. That's the toughest area to regularly manage in a convenient way on Systems. Regular freespace wiping of allocated volumes is pretty easy (scheduled) but not so easy when trying to do the same in unallocated disk space.
Just thinking out loud here...
I understand that defrag operations work on a cluster level and ignore content. But, if a database file is rewritten in its entirety by the application itself, wouldn't it be rewritten in series of clusters with the final cluster possibly having tips (2/3rds cluster for example).
Cluster1F + Cluster2F + Cluster3F + Cluster4H = our file.
..where F=full cluster and H=half cluster.
So what you're saying is the database may work on just the middle of the file sometimes and we could end up with:
Cluster1F + Cluster2H + Cluster3H + Cluster4F = our file
..and there we have cluster 2 and 3 which are not full and have tips.
Ahh I think I got it. With SQL as an example it writes out in 64K segments. So you'd want a 64K cluster size. If there is a size mis-match between the two, segments written out and clustersize, you would end up with one segment being spread across multiple clusters. With the final cluster (for that seg) having tips. And another segment could do the same thing. Now there are two clusters with tips! But all part of the same file!
Defragging would only make the clusters contiguous and sequential. Got that.
You would have to optimize and "compact" the database with the application itself or a utility specifically for that application.
A program like Moo0 Disk Wiper 1.1.4 or Eraser 5.8.8 for WinXP operate on "TotalClustersize-Filesize=Slack" and remaining slack bytes are what get wiped. Erasing everything between the last recorded byte of the file and the end of the last cluster. Any clusters (with database induced slack) in the middle would have to be handled by the database itself through a compact utility. I see.
I would also guess (but don't know for certain) that's how MS Outlook operates and that's why it has a compact function. Here compact removes the dead slack spaces caused by removing an arbitrary number of records. And it "creates" a new logically contiguous file with only one cluster having tip slack. An entire rewrite of the database if you will.
One more question. Do programs like Acronis TI 2009 and onward capture and save ClusterTips? I would guess if doing a sector-by-sector image, then yes. But if not, then no, Acronis would be following the actual file length as reported by the $Metafiles and not grabbing the whole cluster.
I know that filecopy operations via drag'n'drop follow the $MFT and $Metafiles numbers. ClusterTips aren't visible at that level.