Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
and how about the copies in the new local time machine cache? – Thilo Jul 29 '11 at 6:20
@thilo - not likely at all - why not ask that as it's own question? – bmike Aug 4 '11 at 4:56
up vote 8 down vote accepted

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>/<#>/ 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.

share|improve this answer
Thanks for going further on this! – Gauzy Aug 6 '11 at 5:07

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/ This folder still has the previous versions contained within.

After deleting: /.DocumentRevisions-V100/PerUID/0/5/ 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.

share|improve this answer
This is good progress, but I think this only proves the files were deleted, not necessarily deleted securely. To prove secure deletion I would think you would either need to reference Apple's Developer documentation or run file recovery software and see what is recoverable. – Phil M Jul 27 '11 at 23:57
ah, sorry, i misunderstood you. should be a fairly simple experiment for somebody to reproduce and run a recovery app against. i'm not on ADC, so i'm not of much use there. – Gauzy Jul 28 '11 at 1:49
iostat and an otherwise "still" mac should make it easy to see the write bandwidth. – bmike Aug 4 '11 at 4:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.