Multiple untitled docs are saving to same file

  • We just noticed something that is wrong. When our saveToURL:ofType:forSaveOperation:completionHandler override gets called for NSAutosaveElsewhereOperation on two different untitled docs, the url is exactly the same, so the 2nd one overwrites the 1st. Why? How does Cocoa formulate the url for untitled autosaved files?

    Keep in mind we have preservesVersions and autosavesInPlace both returning NO. We've overridden saveToURL so we can direct autosaves to a folder optionally set by the user. But the incoming url is the problem, before we've even touched it.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On 29 Apr 2013, at 19:08, Steve Mills <smills...> wrote:

    > We just noticed something that is wrong. When our saveToURL:ofType:forSaveOperation:completionHandler override gets called for NSAutosaveElsewhereOperation on two different untitled docs, the url is exactly the same, so the 2nd one overwrites the 1st. Why? How does Cocoa formulate the url for untitled autosaved files?

    It's fairly private to Cocoa quite what it uses, and I'm surprised that it might do something this odd/dumb. Can you give us a stacktrace of the call, at least?
  • On Apr 29, 2013, at 11:08 , Steve Mills <smills...> wrote:

    > We just noticed something that is wrong. When our saveToURL:ofType:forSaveOperation:completionHandler override gets called for NSAutosaveElsewhereOperation on two different untitled docs, the url is exactly the same, so the 2nd one overwrites the 1st. Why? How does Cocoa formulate the url for untitled autosaved files?

    The autosaves I've seen use a URL in a temporary directory (with, essentially, a random directory name), but it constructs the file/package name by using a standard name containing a number that's incremented until it finds the first one for which no file already exists -- "(A document being autosaved by XXX)" is the starting name, then "(A document being autosaved by XXX 2)", followed by 3, 4, 5, etc. Since you're not creating anything there, I conclude, it always thinks the starting name is available, and re-uses it.

    > Keep in mind we have preservesVersions and autosavesInPlace both returning NO. We've overridden saveToURL so we can direct autosaves to a folder optionally set by the user. But the incoming url is the problem, before we've even touched it.

    You should generate your own unique file name, then. There's no value in preserving the incoming file name anyway, is there, since you're returning a different URL, right?
  • On 2013 Apr 29, at 15:21, Quincey Morris <quinceymorris...> wrote:

    > You should generate your own unique file name, then. There's no value in preserving the incoming file name anyway, is there, since you're returning a different URL, right?

    Don't be afraid to do what Quincey says, Steve.  Off hand, I can think of at least two places in my NSDocument subclasses where I've had to work around stuff sent to me by Cocoa which makes no sense.

    The document system in Cocoa is really complicated, and in Lion and Mountain Lion it became even more so.  I wonder if anyone at Apple has ever worked out all of the states in all of the corner cases, or if that is even humanly possible.  Maybe in their new building they'll have some really big conference rooms with really big whiteboards.
  • On Apr 29, 2013, at 20:35:00, Jerry Krinock <jerry...> wrote:

    > On 2013 Apr 29, at 15:21, Quincey Morris <quinceymorris...> wrote:
    >
    >> You should generate your own unique file name, then. There's no value in preserving the incoming file name anyway, is there, since you're returning a different URL, right?
    >
    > Don't be afraid to do what Quincey says, Steve.  Off hand, I can think of at least two places in my NSDocument subclasses where I've had to work around stuff sent to me by Cocoa which makes no sense.
    >
    > The document system in Cocoa is really complicated, and in Lion and Mountain Lion it became even more so.  I wonder if anyone at Apple has ever worked out all of the states in all of the corner cases, or if that is even humanly possible.  Maybe in their new building they'll have some really big conference rooms with really big whiteboards.

    Thanks, y'all. I don't know why Apple isn't supplying at least the document's displayName for this.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
previous month april 2013 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