>The "Documents" folder inside the container is meant to be a private area for the app itself, not the user. You could use it à la iOS with a custom file browser, omitting the Finder altogether.
By that definition, the "Documents" folder in a sandboxed app virtually is no different than the Application Support directory. I think it's okay to use it that way In any case, sometimes apps want to allow users to drag and drop files to them, to move files into a directory that the app manages and/or use Services on their files that happen to be in this directory (the only directory a sandboxed app can write to without showing a permissions dialog). The purpose of the files in this directory inside my sandboxed container is defined by my app and the user.
Anyway I didn't create this thread to argue about what my app is doing. You seem to be making excuses for what I consider to be a bug. I don't see why NSSavePanel would redirect the path of a sandboxed container's Documents folder to the "real" documents directory. This actually seems like a way a malicious developer could trick the user into accessing a directory that doesn't belong to him.
1) Create a sandboxed app. Make a documents folder in code (so a Documents folder in the sandboxed container).
2) Have the sandboxed app create a folder named "Chicken" inside the documents directory of the sandboxed container.
3) Create a folder named "Chicken" in the real documents directory in Finder.
4) In the sandboxed app, show an NSSavePanel and set the directoryURL to the Chicken URL (of the sandboxed container).
5) See that the directoryURL in the save panel shown points to "Chicken" in the real Documents folder.
This is what I noticed in debug mode. Maybe I had navigated to the "real directory" and state restoration brought it back on a previous launch; didn't have time to test it thoroughly.
I'm no security nut, the user still has to hit "Save" in the save panel to write to "Chicken" but the behavior doesn't really make sense. Just have the save panel point to the directoryURL that it was told. That's the fix. I almost don't want to mention it because I fear Apple will take away the directoryURL property entirely or throw up a permissions dialog on top of the save panel, something like:
This app wants to set the save location to your folder named "Ciicken". Confirm or Deny
A dialog asking for permission on top of the save panel (which is a dialog asking for permission).
Really, i'm just trying to use the same code path (to handle implementing a Service that can *write* anywhere the *user* wants me to write via NSSavePanel. My app also happens to use the Service it provides itself when fired on files in my own sandboxed container. And *I know* I don't need the save panel to write in this directory, but it just seems silly that I'm *not allowed* to use it.