FROM : John Stiles
DATE : Sun Jul 02 18:20:13 2006
Adam R. Maxwell wrote:
>
> On Jul 1, 2006, at 12:40, John Stiles wrote:
>
>> Dean Snyder wrote:
>>>
>>> Again, with emphasis added, the documentation says, "creates a file at
>>> destination that holds the exact contents of the original file and THEN
>>> deletes the original file". That can only mean that at some point there
>>> are 2 copies of the file. (Notice there is no talk of just manipulating
>>> file references within the file manager's data structures.) That may
>>> not, in fact, be what it does, but that IS what the documentation says
>>> it does. And, of course, the issue is compounded when dealing with
>>> directories (where the documentation actually talks about
>>> "duplicates of
>>> the files and directories").
>>>
>>>
>> Even if it really does just make hard links, even that has
>> undesirable consequences. For example, if a file has /ever/ been
>> hard-linked, it can no longer be used with FSExchangeObjects. The API
>> returns an error instead.
>> http://developer.apple.com/documentation/Carbon/Reference/File_Manager/Reference/reference.html#//apple_ref/c/func/FSExchangeObjects
>>
>
> This is sort of tangential to the original question, but I wonder if
> this is why hard linked files cannot be saved with
> NSDocument/NSDocumentController? A user filed a bug report about this
> against an app I work on, and the only response I could come up with
> was "don't use hard links," which isn't very gratifying. There's no
> way AFAICT to catch that error, either; it's the lame generic message.
>
Yes, this is why. :)
DATE : Sun Jul 02 18:20:13 2006
Adam R. Maxwell wrote:
>
> On Jul 1, 2006, at 12:40, John Stiles wrote:
>
>> Dean Snyder wrote:
>>>
>>> Again, with emphasis added, the documentation says, "creates a file at
>>> destination that holds the exact contents of the original file and THEN
>>> deletes the original file". That can only mean that at some point there
>>> are 2 copies of the file. (Notice there is no talk of just manipulating
>>> file references within the file manager's data structures.) That may
>>> not, in fact, be what it does, but that IS what the documentation says
>>> it does. And, of course, the issue is compounded when dealing with
>>> directories (where the documentation actually talks about
>>> "duplicates of
>>> the files and directories").
>>>
>>>
>> Even if it really does just make hard links, even that has
>> undesirable consequences. For example, if a file has /ever/ been
>> hard-linked, it can no longer be used with FSExchangeObjects. The API
>> returns an error instead.
>> http://developer.apple.com/documentation/Carbon/Reference/File_Manager/Reference/reference.html#//apple_ref/c/func/FSExchangeObjects
>>
>
> This is sort of tangential to the original question, but I wonder if
> this is why hard linked files cannot be saved with
> NSDocument/NSDocumentController? A user filed a bug report about this
> against an app I work on, and the only response I could come up with
> was "don't use hard links," which isn't very gratifying. There's no
> way AFAICT to catch that error, either; it's the lame generic message.
>
Yes, this is why. :)






Cocoa mail archive

