Update for OSX 10.9 Mavericks:
It appears that you can now sort by Date Added in OSX Mavericks. In Trash right click one of the columns and click to check the Date Added column. The click on the column header until the list of files is sorted by Date Added descending.
For OS X 10.7 Lion:
Go to the AppleScript Editor, paste in the following script and save it in /Library/Scripts/Folder Action Scripts:
on adding folder items to this_folder after receiving added_items
repeat with this_item in added_items
do shell script "find " & quoted form of POSIX path of this_item & " -exec touch {} \\;"
end repeat
end adding folder items to
Then…
Right-click on any folder in Finder, go to Services and click Folder Actions Setup.
Cancel the dialog asking which script to attach.
Click the checkbox to Enable Folder Actions
Click the plus sign to choose the Trash.
Press ⌘ cmd + ⇧ shift + G and type in ~/.Trash, click Go or press ↩ return, and then click Open.
On the right side, click the plus sign to choose the AppleScript that you saved earlier.
Thanks to Graham for the link which pointed me in the right direction.
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.
Best Answer
You could try a tool like https://www.prosofteng.com/datarescue-mac-data-recovery/ which has some free tiers to recover limited files.
If your Mac OS supports the FileVault full disk encryption, doing that would be far better and let you never worry about secure erase since everything is cryptographically erased without your password. If that's not an option, use Disk Utility and securely wipe all free space on the drive one time.
I'm assuming you don't have an SSD which don't support secure erase - in that case, see here.