APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Exploring Apple versions

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.

Version Permissions

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

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Exploring Apple file versions

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

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.

Contact us