FROM : Ken Thomases
DATE : Thu May 08 04:36:05 2008
On May 7, 2008, at 9:06 PM, Graham Cox wrote:
> On 8 May 2008, at 10:26 am, Keith Blount wrote:
>
>> The trouble with all of these methods is that they tell you not to
>> rely on fileURL
>
> My interpretation of that advice is that at the time the read... and
> write... methods are called, the document hasn't set up -fileURL, so
> in that sense you can't rely on it (i.e. don't call -fileURL from
> within these methods). But the URL passed to the methods themselves
> as a parameter is definitely reliable. So provided you use the
> parameter you'll be fine.
I think it means more than that. NSDocument tries to be smart about
atomic writes and backups. The URL passed into the write... methods
is not expected to be the same as the document's current location on
disk. You are to write the document, in whole, to the temporary
location provided to you (about which no assumptions should be made),
and then NSDocument will take care of swapping the newly-written
document with the old document and deleting the old document.
Obviously, this runs directly counter to Keith's desires.
Unfortunately, I don't know how to override these smarts in
NSDocument, other than perhaps what I described earlier with
NSFileWrapper.
-Ken
DATE : Thu May 08 04:36:05 2008
On May 7, 2008, at 9:06 PM, Graham Cox wrote:
> On 8 May 2008, at 10:26 am, Keith Blount wrote:
>
>> The trouble with all of these methods is that they tell you not to
>> rely on fileURL
>
> My interpretation of that advice is that at the time the read... and
> write... methods are called, the document hasn't set up -fileURL, so
> in that sense you can't rely on it (i.e. don't call -fileURL from
> within these methods). But the URL passed to the methods themselves
> as a parameter is definitely reliable. So provided you use the
> parameter you'll be fine.
I think it means more than that. NSDocument tries to be smart about
atomic writes and backups. The URL passed into the write... methods
is not expected to be the same as the document's current location on
disk. You are to write the document, in whole, to the temporary
location provided to you (about which no assumptions should be made),
and then NSDocument will take care of swapping the newly-written
document with the old document and deleting the old document.
Obviously, this runs directly counter to Keith's desires.
Unfortunately, I don't know how to override these smarts in
NSDocument, other than perhaps what I described earlier with
NSFileWrapper.
-Ken
| Related mails | Author | Date |
|---|---|---|
| Keith Blount | May 8, 02:26 | |
| Graham Cox | May 8, 04:06 | |
| Ken Thomases | May 8, 04:36 |






Cocoa mail archive

