Lion permission problems

  • 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
  • If I understand you correctly, this sounds like the use case for security-scoped bookmarks:

    http://developer.apple.com/library/mac/documentation/Security/Conceptual/Ap
    pSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/do
    c/uid/TP40011183-CH3-SW16


    (Sent from my iPhone.)

    --
    Conrad Shultz

    On Jun 23, 2012, at 9:17, Matthew Weinstein <mweinste...> 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
  • 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
  • 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?

    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
    >
  • On Jun 23, 2012, at 12:09 PM, Matthew Weinstein <mweinste...> 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
  • 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.

    On Jun 23, 2012, at 1:12 PM, Kyle Sluder wrote:

    > On Jun 23, 2012, at 12:09 PM, Matthew Weinstein <mweinste...> 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
  • On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <mweinste...> 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 <mweinste...> 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
    >
  • 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.

    On Jun 23, 2012, at 1:22 PM, Kyle Sluder wrote:

    > On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <mweinste...> 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 <mweinste...> 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
    >>
  • So if I understand your pattern, you are managing a single "product PDF" which is constructed by your app based upon metadata which describes the specific component PDFs etc that the user has chosen. Those component PDFs reside elsewhere than within your app space, correct?

    On 2012-06-23, at 1:26 PM, Matthew Weinstein <mweinste...> 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.
    >
    > On Jun 23, 2012, at 1:22 PM, Kyle Sluder wrote:
    >
    >> On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <mweinste...> 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 <mweinste...> 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
    >>>

  • Yup! They are contributed by the user, but they stay in the user space; they are read-only. I create a pdfdocument with them and then borrow pages to resequence them (based on a table the user keeps) and spit out a new pdf. The automatic part is that the user can tell the program what to do with extra pages the program finds when they change pdf documents that the program is "monitoring" (actually each document monitors the pdfs added to it, just pointers to the docs, actually).

    On Jun 23, 2012, at 1:41 PM, Erik Stainsby wrote:

    > So if I understand your pattern, you are managing a single "product PDF" which is constructed by your app based upon metadata which describes the specific component PDFs etc that the user has chosen. Those component PDFs reside elsewhere than within your app space, correct?
    >
    >
    >
    > On 2012-06-23, at 1:26 PM, Matthew Weinstein <mweinste...> 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.
    >>
    >> On Jun 23, 2012, at 1:22 PM, Kyle Sluder wrote:
    >>
    >>> On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <mweinste...> 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 <mweinste...> 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
    >>>>

    >
  • I think I see a second problem coming down the pike. the users can add pdfs to the wrapper file through a typical open file or through drag and drop. I get that the NSOpen... allows me to expand entitlements. But does drag and drop? Is there a way to get a bookmark and ask for ongoing privileges for a path I get through drag and drop?
    --Matthew

    On Jun 23, 2012, at 1:41 PM, Erik Stainsby wrote:

    > So if I understand your pattern, you are managing a single "product PDF" which is constructed by your app based upon metadata which describes the specific component PDFs etc that the user has chosen. Those component PDFs reside elsewhere than within your app space, correct?
    >
    >
    >
    > On 2012-06-23, at 1:26 PM, Matthew Weinstein <mweinste...> 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.
    >>
    >> On Jun 23, 2012, at 1:22 PM, Kyle Sluder wrote:
    >>
    >>> On Jun 23, 2012, at 1:16 PM, Matthew Weinstein <mweinste...> 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 <mweinste...> 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
    >>>>

    >
  • On Jun 23, 2012, at 1:26 PM, Matthew Weinstein <mweinste...> 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 <mweinste...> 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 <mweinste...> 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
    >>>
    >
  • On Jun 23, 2012, at 2:02 PM, Matthew Weinstein <mweinste...> wrote:

    > I think I see a second problem coming down the pike. the users can add pdfs to the wrapper file through a typical open file or through drag and drop. I get that the NSOpen... allows me to expand entitlements. But does drag and drop? Is there a way to get a bookmark and ask for ongoing privileges for a path I get through drag and drop?

    Yes. Consult the App Sandbox documentation.

    --Kyle Sluder
previous month june 2012 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today