Does “Secure Empty Trash” securely delete the hidden version files for documents in the Trash in OS X Lion?

Question

The new Versions feature in Lion creates hidden files that store old versions of the document you're working on in case you want to revert back to some older version of the document. If I drag a document to the Trash, then select Secure Empty Trash from the Finder menu, do the hidden version files get securely deleted along with the document?

Answer 1

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:

1. A ~160 MB file was created in /.DocumentRevisions-V100/staging/. The hard link count for this file is 1.
2. That file appeared to move to /.DocumentRevisions-V100/PerUID/<UID>/<#>/com.apple.documentVersions. The hard link count remained 1.
3. 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.

Answer 2

I just tested this out, and it appears that the older files do indeed get deleted. It did not matter if I chose Secure Empty Trash or simply emptied the trash normally, they were also deleted.

A little more detail:

To test this, I enabled the root user to allow me to peer into /.DocumentRevisions-V100 and the files within. The exact structure of this folder and its contents are better explained over in John Siracusa's Lion review (Internals, Document Revisions).

I created a couple files, then made some changes, saving new versions. The folder that contained the revisions populated with new files as I saved new versions. Within this top level folder, there's a folder called PerUID, which houses subfolders for each user account. Each user account folder contains a series of numbered folders, one folder for each file that has revisions saved. Thus, the actual revisions are saved as files a few levels down in this hierarchy, with hashed filenames. Emptying the trash (either way) would delete these files, but the preceding folder structure would remain in place.

Before deleting: /.DocumentRevisions-V100/PerUID/0/5/com.apple.revisions This folder still has the previous versions contained within.

After deleting: /.DocumentRevisions-V100/PerUID/0/5/com.apple.revisions This folder still exists, but it is empty.

I did not inspect the other folders within /.DocumentRevisions-V100/, so I did not check the databases that are contained within them. Siracusa goes into more detail, but they seem to exist to contain databases to track changes and map the user's files to the revisions saved by the system. I'm fairly certain that no document contents are saved there, though I'm not sure about filenames, and if filenames are present, if they're hashed or not.