Re: Modifying the save path in an NSDocument based application
The answer, if anyone else is thinking of answering this question, is to use
NSFileWrapper - ensuring that "Document is distributed as a bundle" is
unchecked for the folder that you generate.
Simples. And my apologies to all here for not investigating further before
posting a question.
On 18 Sep 2013, at 20:54, Pax <45rpmli...@googlemail.com> wrote:
> Okay, the plot thickens. I've now updated my app for the app store -
> sandboxing is now enabled. Sandboxing breaks the save path modification,
> and particularly my creation of a folder:
>
> if(![fileManager createDirectoryAtPath:directory
>withIntermediateDirectories:NO
> attributes:nil
> error:&error])
> {
> NSLog(@"Failed to create directory \"%@\". Error: %@ - this
> save will most likely fail entirely.", directory, error);
> }
> else
> { ... }
>
> With sandboxing enabled, the creation of the directory always fails - unless
> the user opts to save in the Downloads directory. Most odd.
>
> The user can choose to save an undecoded version of the file wherever they
> like. I have set read/write access for the Downloads Folder - which probably
> explains this. How can I get read/write access to wherever the user chooses
> to extract the files (most likely Documents, loose in their home folder, or
> the desktop?)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
Okay, the plot thickens. I've now updated my app for the app store -
sandboxing is now enabled. Sandboxing breaks the save path modification, and
particularly my creation of a folder:
if(![fileManager createDirectoryAtPath:directory
withIntermediateDirectories:NO
attributes:nil
error:&error])
{
NSLog(@"Failed to create directory \"%@\". Error: %@ - this
save will most likely fail entirely.", directory, error);
}
else
{ ... }
With sandboxing enabled, the creation of the directory always fails - unless
the user opts to save in the Downloads directory. Most odd.
The user can choose to save an undecoded version of the file wherever they
like. I have set read/write access for the Downloads Folder - which probably
explains this. How can I get read/write access to wherever the user chooses to
extract the files (most likely Documents, loose in their home folder, or the
desktop?)
On 17 Sep 2013, at 15:20, Jerry Krinock wrote:
>
> On Sep 17, 2013, at 07:49:56, Pax <45rpmli...@googlemail.com>
> wrote:
>
>> I thought that this would be nice and simple
>
> No. Overriding anything in the AppKit document architecture is playing with
> fireworks, especially since Auto Save and Versions. To be safe, when you're
> "done", retest all of the functions: Duplicate, Rename, Move To, Browse All
> Versions, etc., in all OS X versions you're deploying to.
>
> On 2013 Sep 17, at 06:41, Steve Mills wrote:
>
>> You might try overriding
>> saveToURL:ofType:forSaveOperation:completionHandler: instead. writeToURL is
>> at a very low level in the save operation, and if you look at the stack, I
>> bet writeSafelyToURL:ofType:forSaveOperation:error: is one of the callers of
>> writeToURL.
>
> Steve's advice looks good to me. For a picture of the Save operation, in
> Xcode's Documentation browser, check out
>
> Document-Based app Programming Guide for Mac > Alternative Design
> Considerations > Message Flow in the Document Architecture > Saving A
> Document > Figure 6-6 at the bottom of the page
>
> Supposedly this document has recently been updated to reflect Auto Save and
> Versions, but I haven't verified that.
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/45rpmlists%40googlemail.com
>
> This email sent to 45rpmli...@googlemail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
Thanks Jerry, Thanks Steve, You guys rock! If you're ever in London I definitely owe you beer! On 17 Sep 2013, at 14:41, Steve Mills wrote: > > You might try overriding saveToURL:ofType:forSaveOperation:completionHandler: > instead. writeToURL is at a very low level in the save operation, and if you > look at the stack, I bet writeSafelyToURL:ofType:forSaveOperation:error: is > one of the callers of writeToURL. What that does is first write the file to a > temp file, then if all goes well, moves it to the actual location, replacing > the original file if it exists. So you'll want to let that happen. But up in > saveToURL you should be able to point it to your new dir at a higher level, > before writeSafelyToURL does its thing. > > -- > Steve Mills > office: 952-818-3871 > home: 952-401-6255 > cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
On Sep 17, 2013, at 07:49:56, Pax <45rpmli...@googlemail.com> wrote: > I thought that this would be nice and simple No. Overriding anything in the AppKit document architecture is playing with fireworks, especially since Auto Save and Versions. To be safe, when you're "done", retest all of the functions: Duplicate, Rename, Move To, Browse All Versions, etc., in all OS X versions you're deploying to. On 2013 Sep 17, at 06:41, Steve Mills wrote: > You might try overriding saveToURL:ofType:forSaveOperation:completionHandler: > instead. writeToURL is at a very low level in the save operation, and if you > look at the stack, I bet writeSafelyToURL:ofType:forSaveOperation:error: is > one of the callers of writeToURL. Steve's advice looks good to me. For a picture of the Save operation, in Xcode's Documentation browser, check out Document-Based app Programming Guide for Mac > Alternative Design Considerations > Message Flow in the Document Architecture > Saving A Document > Figure 6-6 at the bottom of the page Supposedly this document has recently been updated to reflect Auto Save and Versions, but I haven't verified that. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
On Sep 17, 2013, at 07:49:56, Pax <45rpmli...@googlemail.com> wrote: > I have a slightly odd requirement in that I need to modify, under certain > circumstances, the save path used for an NSDocument based application. The > reason for this is that I may, depending on the format chosen by the user, > need to unpack the data into multiple files. Under this circumstance, I want > to create a folder at the location specified by the user, with the name of > the source file (less the extension) as the folder name, and then I'll unpack > the source file into this directory. > > I thought that this would be nice and simple - but it seems that the URL used > when saving is an intermediate URL. My file doesn't get created at the final > destination location (and, because it doesn't, I can't easily modify the > path). What I planned to do is this: > > - (BOOL)writeToURL:(NSURL *)url ofType:(NSString *)inTypeName error:(NSError > **)outError > When I check url I get something like > file://localhost/private/var/folders/6w/6dmwl9c938g4m94jm7s_8ml8gn/T/TemporaryItems/(A%20Document%20Being%20Saved%20By%20Extractor)/Christmas.ext You might try overriding saveToURL:ofType:forSaveOperation:completionHandler: instead. writeToURL is at a very low level in the save operation, and if you look at the stack, I bet writeSafelyToURL:ofType:forSaveOperation:error: is one of the callers of writeToURL. What that does is first write the file to a temp file, then if all goes well, moves it to the actual location, replacing the original file if it exists. So you'll want to let that happen. But up in saveToURL you should be able to point it to your new dir at a higher level, before writeSafelyToURL does its thing. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Modifying the save path in an NSDocument based application
I have a slightly odd requirement in that I need to modify, under certain
circumstances, the save path used for an NSDocument based application. The
reason for this is that I may, depending on the format chosen by the user, need
to unpack the data into multiple files. Under this circumstance, I want to
create a folder at the location specified by the user, with the name of the
source file (less the extension) as the folder name, and then I'll unpack the
source file into this directory.
I thought that this would be nice and simple - but it seems that the URL used
when saving is an intermediate URL. My file doesn't get created at the final
destination location (and, because it doesn't, I can't easily modify the path).
What I planned to do is this:
- (BOOL)writeToURL:(NSURL *)url ofType:(NSString *)inTypeName error:(NSError
**)outError
//Bunch of code and then...//
NSString *filename = [[url absoluteString] lastPathComponent];
NSString *directory = [[[url absoluteString]
stringByDeletingLastPathComponent]
stringByAppendingFormat:@"/%@",[filename
stringByDeletingPathExtension]];
NSFileManager *fileManager= [NSFileManager defaultManager];
NSError *error = nil;
if(![fileManager createDirectoryAtPath:directory
withIntermediateDirectories:YES
attributes:nil
error:&error])
{
success = false;
}
else
{
url = [NSURL fileURLWithPath:[NSString
stringWithFormat:@"%@/%@",directory,filename]];
}
When I check url I get something like
file://localhost/private/var/folders/6w/6dmwl9c938g4m94jm7s_8ml8gn/T/TemporaryItems/(A%20Document%20Being%20Saved%20By%20Extractor)/Christmas.ext
Does anyone have the key to what I should be doing - because I'm clearly
approaching this from the wrong angle!
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
