Here is a border case to consider.
Have doc1 containing an item that links to file1. Want to copy the
item to doc2, and file1 to file2 maintaining the same relative path.
Q: does the copied item link to file1 or to file2?
A: it depends, among others on the order of copying.
Scenario 1:
First copy the file, then the item.
The copied item will find file2 through the relative path, so it
links to that file2.
Scenario 2:
First copy the item, then the file.
The copied item will initially not find file2 at the relative path,
so it links to file1 through the absolute path. When file2 is
created, this will not change because the FSRef pointing to file1 has
been created, and moreover I think the alias has been updated. I
think we should do both, for efficiency and to avoid being fragile
for other situations.
This becomes even more hairy of doc1 is a new document that is saved
later on.
So an important question is: when do we create the FSRef, and when do
we update the alias?
Christiaan
On 18 Oct 2007, at 11:38 PM, Christiaan Hofman wrote:
On 10/18/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
On Thursday, October 18, 2007, at 08:35AM, "Christiaan Hofman"
<[EMAIL PROTECTED]> wrote:
>> Still don't see how to handle new documents.
I forgot about that until after I sent the message. You previously
suggested caching the save-destination URL ivar off in BibDocument,
and I think that would work with a new accessor, as long as we can
override a point that has the real destination.
>OK, the docs say it can use both relative and absolute paths, you
can even
>specify in which order it searches. By default relative first, then
>absolute, then node ID.
Good...I didn't see that. Interesting that Apple's had relative
path-based solutions built in to Carbon for all these years, but
Cocoa mainly requires absolute path/URL.
Well, cocoa also does not support aliases to start with.
>I saw that using FSResolveAlias the alias is automatically
updated. When we
>use (different) relative paths (e.g. for Export) this is unwanted.
So either
>we have to make a copy of the alias, or use FSMatchAlias, which is
a bit
>more work. Perhaps we should not keep a BDAlias but an
AliasHandle, because
>we need to do some custom things (like this) that BDAlias can not
handle.
>Also when there is no file name we may just use an alias without
base path.
>The alias is used basically just for backup, when the FSRef is
invalid or
>null. We may want to update it in some cases though (for a Save
As, or when
>creating a new file object, or when copying items between documents).
>Anyway, I think we just should need a BDSKAliasFile subclass that
contains
>an FSRef and an alias for backup.
Yeah, that's roughly the same conclusion I came to when I woke up
thinking about it this morning :/. I also need to forego all
thought of optimization while we try to get this working! Maybe
even a new (public) class altogether, since the current BDSKFile
wouldn't be able to figure out which class to create? I guess a
new initPersistentFileWithPath: or something might do as well. We
probably don't want to inflict aliases on the orphaned file finder.
--
adam
Another thing, when an item is generated it does not know about its
document (and therefore the base path). So we need to find a way to
handle that. Perhaps the alias should be resolved to an FSRef lazily?
Christiaan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
