[tzs]

Wouldn't security-scoped bookmarks solve some of the problems he describes? From the sandbox design guide:

--------------------------------

Starting in Mac OS X v10.6, the NSURL class and the CFURLRef opaque type each provide a facility for creating and using bookmark objects. A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current location. A bookmark’s association with a file-system resource (typically a file or folder) usually continues to work if the user moves or renames the resource, or if the user relaunches your app or restarts the system.

In an app that adopts App Sandbox, you must use a security-scoped bookmark to gain persistent access to a file-system resource.

Security-scoped bookmarks, available starting in Mac OS X v10.7.3, support two use cases:

• An app-scoped bookmark provides a specific sandboxed app with persistent access to a user-specified file or folder.

For example, if your app employs a download or processing folder, present an NSOpenPanel dialog to obtain the user’s intent to use a specific folder. Then, by creating a security-scoped bookmark for that folder and storing it as part of the app’s configuration (perhaps in a property list file or using the NSUserDefaults class), your app acquires a means to obtain future access to the folder.

• A document-scoped bookmark provides a specific document with persistent access to a file.

For example, a code editor typically supports the notion of a project document that refers to other files and needs persistent access to those files. Other examples are an image browser or editor that maintains an image library, in which the library file needs persistent access to the images it owns; or a word processor that supports embedded images, multimedia, or font files in its document format. In these cases, you configure the document format (of the project file, library file, word processing document, and so on) to store security-scoped bookmarks to the files a document refers to. (A document-scoped bookmark can point only to a file, not a folder.)

A document-scoped bookmark can be resolved by any app that has access to the bookmark data itself and to the document that owns the bookmark. The document can be a flat file, or a document distributed as a bundle.

--------------------------------

[feralchimp]

Wow thanks; I had not realized there were 10.7.3 related updates to the Sandboxing Guide.

[lukifer]

Thanks for the suggestion, this is very helpful. Do you know if this also bypasses issues of file ownership, or is this only relevant to the sandbox? (Editing of non-owned files using an admin password is a gorram nightmare on modern OS X.)

[Volpe]

I'm pretty sure it should stay that way... no?

[lukifer]

It should be non-trivial for both user and developer, but it shouldn't require interprocess communication and reading fifty-ish pages of docs. It's a little insane, and I gave up on trying. (It was a simple GUI for editing a particular system file, similar to what Cocktail does; like sudo vi, but more convenient.)

[seanalltogether]

Bookmarks are a working solution, the problem is getting the user to locate those urls in the first place. I'm having many of the same problems that the OP mentions and explaining to the user how to locate folders and files correctly is a usability nightmare.

"Click the button below, locate file xyz and 'Open' it to proceed"

I would be perfectly ok with a system "Grant permission to xyz" dialog, but the open file dialog is a terrible way of requiring access to a file or folder.

[msbarnett]

> "Click the button below, locate file xyz and 'Open' it to proceed"

Rather than presenting it as some pointless mechanical chore in which you direct a user to a specific file in a known place, wouldn't "Choose where you would like Foo.app to save your XYZ (project/file/whatever)" make a lot more sense?

[seanalltogether]

It's not about saving though, it's about reading files that already exist in certain locations.

Imagine for instance an application that helps you clean up your downloads folder, but wouldn't be appropriate to use on other folders on your system. It's not the best example, but it illustrates how much of a usability mess it is to ask the user to locate the folder for you through an open file dialog, and then have to reject it if they select the wrong thing.

[msbarnett]

That's a fairly niche case, though. Personally I'm comfortable sacrificing it in favor of not giving apps full read-write access to everything on my system by default.

I can see how there are very specific cases in which it would be too cumbersome, but it probably works in > 80% of cases, and it's pretty clear that those 80% apps are who the App Store is aimed at.

Edit: Thinking about this some more: not to pick on your example, but the Downloads folder actually does need to be located by the user, because it's not actually in a fixed location (it defaults to $HOME/Downloads, but that's not where mine is located, for instance).

There really aren't many cases that I can dream up in which you can absolutely be certain of a file or folder's location, such that an Open Dialog is totally superfluous.

[seanalltogether]

It's not really niche though, the entire Utilities and Dev Tools section of the app store are full of these kinds of apps that provide users with convenient management of data in predetermined locations, my own included http://itunes.apple.com/us/app/space-gremlin/id414515628?mt=...

[acqq]

Imagine if there were "just pass a path" APIs. Apps could then just pass a path, users wouldn't care where the path points to even if it's shown to them. "Yeah whatever." Clearly defies the idea of the sandbox.