[ejdyksen]

Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1].

For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed container.

[1] https://developer.apple.com/library/mac/documentation/Securi...

[quotemstr]

Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.

[chopin]

But these are applications for knowledgeable users I think which is not the type of users the GGP is talking about. For these it might be ok to ask for permission. Or to grant it automatically if you are root or sudo'ed. And many use cases could get around with allowing silently to write if the file has been previously been opened by the same application.

[quotemstr]

I will not use a system that pops up some kind of UAC-like approval dialog for every call Emacs makes to open(2).

[wlesieutre]

The OS X sandbox doesn't work that way. If you do "Open" and pick the root of your hard drive one time, the application gets and keeps access to the entire drive.

Disk scanning programs like DaisyDisk from the app store have to make you do this before they can get any information about disk usage.

[ejdyksen]

Well, of course, sandboxing is opt-in, and there are still lots of programs out there that don't use them.

I'm not sure Emacs or vim, as an example, would ever be able to be sandboxed from the filesystem.

[wtallis]

Aquamacs seems to use the system dialogs with no trouble.

[quotemstr]

Sure, File->Open invokes the system dialog. Not C-x C-f. Not automatic filename history, or tags table traversal, or perusal of the M-x grep results buffer, and so on. Emacs is a generic runtime environment and needs generic file access.