When I bought my new iMac, I took advantage of this opportunity for a fresh start and created a new, non-administrative account for my daily use. The idea is just additional safety and the inconvenience factor is quite low. For the most part, all that changes is that I actually have to type an administrator name and the password when challenged. For the very few cases where I need sudo access, I either use fast user switching or just open Terminal, su to the administrative user and then issue my sudo command. Easy enough and it makes me feel a little safer.
When I made the switch, I of course had files under the old account. Some were things I knew I'd need immediately, so I copied them to the new account and changed permissions. Others were things I might need, but then again I might not. What to do about those?
Many of them were TextEdit files in the Documents directory. Rather than copying hundreds of files that I might never need, I added extended permissions with OS X ACL's. I figured I'd open them in situ as I needed them.
That rather immediately ran me smack into version trouble.

I'd choose to duplicate the file as suggested, but a few minutes later, I'd get more problems - the same message would pop up as TextEdit's versioning tried to automatically save my changes.
The copied file had correct permissions:
-rw-r--r-- 1 tony apl 2214 Nov 4 11:16 foobar.rtf
So what was causing this?
I knew from Ars Technica that versions are stored in /.DocumentRevisions-V100. But why should that be a problem? The "PerUID" directory should store my versions, right? That's owned by me, so TextEdit should be able to write there on my behalf.
sh-3.2# ls -l total 0 d--x------ 17 tony wheel 578 Nov 4 11:17 502 sh-3.2# pwd /.DocumentRevisions-V100/PerUID sh-3.2# ls -l total 0 d--x------ 17 tony wheel 578 Nov 4 11:17 502
And it does - as long as I am not trying to work on a document in that admin user's directory structure.
This has to be something else. Could it be sandboxing?

TextEdit runs "sandboxed". As explained at this Ars Technica post, this restricts TextEdit:
It might seem like any nontrivial document-based Mac application will, at the very least, need to declare an entitlement that will allow it to both read from and write to any directory owned by the current user. After all, how else would the user open and save documents? And if that's the case, wouldn't that entirely defeat the purpose of sandboxing?
Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action.
It doesn't quite make sense to me that this would restrict versioning, so it may be a legitimate bug rather than intended consequence, but it does seem reasonable to me that sandboxing might be the cause.
More Articles by Anthony Lawrence - Find me on Google+ 2011-11-04
Click here to add your comments - no registration needed!
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar
Printer Friendly Version
Exploring Apple Document versions Copyright November 2011 Tony Lawrence
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Printer Friendly Version