[quote=248114:@Jeff Tullin]Essentially, because Im using a standard file open/save dialog, I don’t need to ask for access to any particular folder.
[/quote]
I assume double-clicking, dropping on top of the icon and dropping over the UI all are equivalent to open/save dialogs and provide write-access to the files.
Are there any entitlement or procedure where opening a file gives access to the folder itself? I’m thinking being able to save files alongside the opened file (for example, automatically creating a text metadata file to go along a video file) without having to ask for the permission again.
I understand this is not possible, since programs like The Unarchiver or Movist have to keep asking access to the folders from dropped/opened files, but perhaps I’m misunderstanding, since this sounds like an entitlement that should sensibly exist.
[quote=247629:@Tim Jones]If you swap those numbers, you get the most stable OS X version ever shipped:
10.4.11[/quote]
Hardly surprising with 11 bug fix releases.
With yearly releases it barely gets above .5, but at long last Apple seems to have seen the error of their ways and considers going back to 18 month release cycles, or more likely have Snow Leopard type releases every other version where bug fixing and sppeding things up are the priority.
No. That’s unexpected behavior. If you need to save files next to each other ask for a location to save a folder and put your next to each other files in the folder.
[quote=248068:@Jeff Tullin]My app can open pictures
It can create user documents and open the same.
It can print.[/quote]
Okay, so what you need as the bare minimum are:
Sandbox
security.files.user-selected.read-write
security.print
You do not this one, otherwise the Open & Save dialogs don’t show.[quote=248129:@Eduardo Gutierrez de Oliveira]Are there any entitlement or procedure where opening a file gives access to the folder itself? I’m thinking being able to save files alongside the opened file (for example, automatically creating a text metadata file to go along a video file) without having to ask for the permission again.[/quote]
Currently there isn’t that I’m aware of. Once you get the folderitem from the open and save dialog, that’s all that you are allowed to access, you can’t even change the file name.
There are several things that can be done instead.
Ask the user to choose the folder to save to, not the file and then you can write whatever you like.
Use a Document Package, it acts like a file, smells like a file, but is in fact a folder, so you can create and store multiple files in one location.[quote=248129:@Eduardo Gutierrez de Oliveira]I assume double-clicking, dropping on top of the icon and dropping over the UI all are equivalent to open/save dialogs and provide write-access to the files.[/quote]
Yes.
It used to be that it was advisable to do this only when using Temporary Entitlements, but for regular entitlements. What next?
[quote=248175:@Carlo Rubini]@Sam Rowlands
You are right. I stand corrected.[/quote]
I wasn’t trying to correct you, I wouldn’t be surprised if this actually happened, that one day we have explain why our app needs any entitlement.
Apple are really locking down on anything that might even be slightly harmful, sometimes to the point where I feel they’re a little too security conscious.
I feel with it getting easier and easier to make apps, some people have really stupid ideas. People are coming up with interesting ways to cause unexpected behavior, and not thinking about how it would feel to be a user.
Apple’s limitations, while occasionally cumbersome, are helping provide a more consistent and predictable user experience.
[quote=248155:@Sam Rowlands]Currently there isn’t that I’m aware of. Once you get the folderitem from the open and save dialog, that’s all that you are allowed to access, you can’t even change the file name.
There are several things that can be done instead.
Ask the user to choose the folder to save to, not the file and then you can write whatever you like.
Use a Document Package, it acts like a file, smells like a file, but is in fact a folder, so you can create and store multiple files in one location.
[/quote]
I’m actually in favor of entitlements, but I feel there’s a couple critical ones for some types of apps. This is a good example, since two of the default ways to work in OSX are in direct conflict with the current entitlements.
My two examples I feel work well to exemplify very basic and justifiable functionality:
-When you double-click a file you only get permission for that file. Not for its containing folder. So double-clicking a compressed file doesn’t allow The Unarchiver to uncompress the file automatically (which is, like, its sole reason to exist). It has to cumbersomely request access to the same folder you double-clicked on.
-When you double-click a movie Movist needs to check the containing folder for subtitle files. It also has to cumbersomely ask for permission to read the same folder the file you just double-clicked on is.
Obviously, in neither case you start from the folder or can use bundles/document packages.
I like entitlements, but I feel there should be one for “containing folder and subfolders” (read and/or write) entitlement and Apple would then police its use (and abuse). That it doesn’t even exists is baffling to me.
Excellent cases.
One small quibble with the zip files though:
It can be argued that asking for a folder to unpack to is sensible.
It certainly is if the archive has been supplied on a CD, or is in a folder where you dont have write permissions.
Or in the case of the Downloads folder, if you have been sent an application, its the Applications folder you would want the unpacked file/s to go to.
But it certainly gets in the way of someone who wants to ‘unpack here’
hmmm… You’ve stirred something hidden in the depths of thine mind… Remember when Sandboxing was first introduced, you couldn’t use any SQL databases, and then all of sudden it’s a non-issue… I don’t recall ever seeing an API added for it, I wonder if there’s an API however or some other mechanism that gets around this?
As for the unarchiver example; it’s a pretty valid one, only non-sanboxed apps (such as most of the apps that Apple include) can have free reign.
This one; is one of those things… MP4 files have locations for subtitles, so they can be included within the same file. I don’t know about other format; movie files that are often downloaded from #ahem# sites do seem to include these separately, even when downloading MP4 files.
In Taiwan, a lot of the downloaded movies have burned in subtitles; so you get 'em even if you don’t want 'em!
Don’t we still have problems when updating the database file of a sandboxed app? For instance, if I double-click a SQLlite database file positioned on the desktop, make some modifications, and perform myDatabaseFile.update, then I get database error 14: unable to open the file. Therefore when I open a file I use to move it to the app’s container, and at the end I move it back to its original location.
Or am I doing something wrong?
You must copy the SQLite database outside of your application to your Preferences area (or generate a new files there) before you can edit it. You cannot even open it read-only ‘inside’ your application, even if the database file is locked.
Sam, I’m getting confused. Do you mean that, in a sandboxed app, DB records can be updated without having the DB file moved/copied into the container or without modifying the plist?
NSFilePresenter: is not this step unnecessary?
Reading the doc you referred to, I see also “NSIsRelatedItemType”: are we supposed to something with it?
It’s easy to link the example with unsavory practices, but the “work in the same folder as the file” is a common practice. You could argue OSX does it itself when working with files in non-Mac filesystems (creates .DS_Store files and directories as needed) and it would also affect any file format that is collection of files but can’t go into a container folder (Xojo’s VCS format comes to mind).
My example about an unpacker is also a common one and there’s tons when dealing with legacy formats and files (for example, creating “thumb.db” files in picture folders, for other programs to read).
I’m unfamiliar with this. I assume we can’t just use it or this would be a solved problem. I’m sure the problem can be worked around, since programs like Filebot exist in the MAS without having to ask for permissions each time they create ancillary files.
Is this something we could take advantage as well? I’ll check it out. Already been discussed in the forums here and here (to which I had already replied but had forgotten by now). Bundled by MBS here.
[quote=248209:@Jeff Tullin]It can be argued that asking for a folder to unpack to is sensible.
It certainly is if the archive has been supplied on a CD, or is in a folder where you dont have write permissions.
Or in the case of the Downloads folder, if you have been sent an application, its the Applications folder you would want the unpacked file/s to go to.
But it certainly gets in the way of someone who wants to ‘unpack here’[/quote]
Not sure I agree this is related. Read/write permissions are something parallel but unrelated to entitlements. The job of entitlements, in this case, is precisely controlling write permissions to places you could conceivably write to but perhaps shouldn’t without the user’s knowledge.
My point was that “write access to the containing folder” of a file should be an entitlement like the others, as it’s a common use-case and it missing introduces incredibly annoying requirements to the user (folder selection every time you double click a file, in both cases above, for example).
That’s what the document is saying, that since OS X 10.8.2 SQLLite databases should just work, without having to move them around.
[quote=248349:@Carlo Rubini]NSFilePresenter: is not this step unnecessary?
Reading the doc you referred to, I see also “NSIsRelatedItemType”: are we supposed to something with it?[/quote]
According to the Apple Docs, for a SQLlite database you do not need this, but in the example of a movie file have subtitles files next to the movie file, this protocol will help (along with a modified plist file).