My guess is no, but this is not a definitive answer.
I first created a very large (~160 MB) .txt file, and made changes to the file in TextEdit. As expected, that file and its versions showed up in /.DocumentRevisions-V100/PerUID. The files appeared to be ~160 MB to ls, but according to du -h they used 0B on disk. The hard link count for each file was 1. A folder called .cs (chunk storage) under /.DocumentRevisions-V100 had grown by about 110 MB.
Every time I changed the file, the following happened in /.DocumentRevisions-V100:
- A ~160 MB file was created in
/.DocumentRevisions-V100/staging/. The hard link count for this file is 1.
- That file appeared to move to
/.DocumentRevisions-V100/PerUID/<UID>/<#>/com.apple.documentVersions. The hard link count remained 1.
- That ~160 MB file became 0B, and the size of
/.DocumentRevisions-V100/.cs grew by about 2 MB.
The free space of the drive (df) was consistent with what du told me. Free space would go down significantly, and then return to nearly what it was before saving a new version.
Next, I tried to shred the file with Secure Empty Trash. OS X seems to use a program called Locum to securely delete the file. Attaching fs_usage to Locum shows an awful lot of reads and writes to the original .txt file. While Locum is doing its thing, all the versions under /.DocumentRevisions-V100/PerUID can still be accessed with data intact. After Locum is done writing over the data, it unlinks the original .txt file, and the versions in /.DocumentRevisions-V100/PerUID suddenly disappear. Locum then moves on to anything else in the Trash, while never touching /.DocumentRevisions-V100.
Whatever is in /.DocumentRevisions-V100 is not being securely erased.
EDIT: I should add that whatever is in /.DocumentRevisions-V100 is somehow obfuscated or compressed (the folder was only ~120 MB). I haven’t yet read the versions or filesystem sections of Siracusa’s review… maybe there are clues in there.
I have two suggestions. My first is to try creating a folder called .Trashes elsewhere and moving it such that it would overwrite the original folder; it's possible that this would leapfrog the problem (I used a similar method to fix a problem I was having a few months ago).
Alternatively, if the external drive is FAT32, have you tried booting a Linux distro from a USB drive and using that? Alternatively you could plug the external drive into a Windows machine (Boot Camp/VirtualBox?) and see whether that can delete the offending folder.
Best Answer
You can erase free space using Disk Utility. (
/Applications/Utilities/Disk Utility.app).In the sidebar of Disk Utility, select “Macintosh HD” (or the drive where you’d originally stored the file). At the top of the window, select the “Erase” tab. Towards the lower left-hand corner of the window, there’s a button labelled Erase Free Space. This lets you overwrite all of the free space on the drive (which is where your deleted file currently resides). You can choose a one-pass, three-pass or seven-pass erase — hopefully that’s more than enough. And if not, I guess you can just do it multiple times.
As always with Disk Utility stuff, be a little careful. I did this a couple of years ago with a three-pass erase, something screwed up and I had to restore from a backup :(