Re: Lion permission problems
Re: Lion permission problems
- Subject: Re: Lion permission problems
- From: Kyle Sluder <email@hidden>
- Date: Sat, 23 Jun 2012 14:04:50 -0700
On Jun 23, 2012, at 1:26 PM, Matthew Weinstein <email@hidden> wrote:
> Unfortunately that undoes the automation idea. The time saving here is that by just re-saving the pdf, the app when the document is opened recombines it based upon the rules that the user set up. Basically you're forcing the user to recreate the sequence of files each time anew.
I believe "re-saving" the PDF should preserve your security-scoped bookmark, as long as the saving app preserves the file's metadata before it overwrites the contents. (Whether this works with safe-saving, I'm not sure. I believe it should, but could be wrong.)
That said, could you use Automator and Folder Actions to implement your automation? This kind of filesystem-based automation is useful right now, but the trend definitely seems to be towards hiding the filesystem.
--Kyle Sluder
>
> On Jun 23, 2012, at 1:22 PM, Kyle Sluder wrote:
>
>> On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <email@hidden> wrote:
>>
>>> The whole idea of the app is so that users can automate the combining of different PDFs; users should be able to swap out different pdfs and then the program will recombine them. The program remembers (saves in a wrapper) the pdfs that have been combined. Sort of defeats the purpose if the users can't substitute say this year's calendar for last year's.
>>
>> So your app's workflow relies on the user understanding and manipulating the filesystem? Apple seem to be encouraging developers to provide interfaces that don't require specific filesystem layouts. In other words, you control the filesystem under your container (which the user should never see) and the user controls the filesystem everywhere else (the layout of which your program should not rely on).
>>
>> Instead of requiring the user to replace the files using Finder, can they just replace the files using your app? You would keep the source PDFs and all the combined results inside your document wrapper.
>>
>> --Kyle Sluder
>>
>>>
>>> On Jun 23, 2012, at 1:12 PM, Kyle Sluder wrote:
>>>
>>>> On Jun 23, 2012, at 12:09 PM, Matthew Weinstein <email@hidden> wrote:
>>>>
>>>>> I think the temp.security thing will work, but I'm wondering what happens if a user replaces a file in the directory by one with the same name; does the os know it's not the original file?
>>>>
>>>> Security scoped bookmarks are attached to the file itself, so if the file is replaced you will not be able to access the new file that exists at that path.
>>>>
>>>> May I ask what motivated you to choose a project-oriented document structure (components located outside the document itself) rather than a compound document structure (PDFs copied or moved into your doc bundle)?
>>>>
>>>> --Kyle Sluder
>>>>
>>>>>
>>>>> On Jun 23, 2012, at 9:53 AM, Alex Zavatone wrote:
>>>>>
>>>>>> From what I have read in the docs, accessing files outside of the approved areas/domains (music, photos, documents(?) ) will ALWAYS require user interaction.
>>>>>>
>>>>>> Apple is really screwing us in this one.
>>>>>>
>>>>>> I hope that Conrad is right with his suggestion.
>>>>>>
>>>>>> On Jun 23, 2012, at 12:17 PM, Matthew Weinstein wrote:
>>>>>>
>>>>>>> Dear cocoa-dev,
>>>>>>> So I'm wondering how in the maze of sandboxed apps how to get my app to work properly. What it does is wrap around pdf files so that they can be combined, separated; etc. It doesn't actually change the original pdfs, just remembers their locations, reads them in and then writes to a different pdf (as the user requests).
>>>>>>>
>>>>>>> In addition it opens a specific wrapper on launch which contains standard elements that a user might want to add to their pdf (blank pages, etc.). The file is just a typical file that the program creates, stored at a location provided by the user, so that they can add their own elements to this wrapper.
>>>>>>>
>>>>>>> The first time the program is run, it doesn't find this special wrapper, asks the user where they want it it, they pick a spot (home or documents), the program creates a directory, copies the needed files out of its bundle, it opens the file, and all is well, the elements from the "fixings" wrapper appear in a menu on the menu bar.
>>>>>>>
>>>>>>> However, the second time the program is run, i.e., once the files have been put in place and I try to access them, I get a "257" error on [[NSDocumentController sharedDocumentController] openDocumentWithContentsOfURL: myurl display: YES error: &err]; Which seems to mean I don't have permission...
>>>>>>>
>>>>>>> It doesn't matter where the user saves the file; I get the 257 error. I did all of this because when I created the directory using the NSHomeDirectoryForUser(NSUserName()) and submitted the application, Apple complained and said I needed to ask the user where to put it; but if I do I get a 257 subsequent times the program is run.
>>>>>>>
>>>>>>> Any ideas on how to do this or get beyond the error code?
>>>>>>>
>>>>>>> --Matthew
>>>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden