On 10/18/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>
> On Sep 25, 2007, at 01:56, Christiaan Hofman wrote:
>
> > On 25 Sep 2007, at 5:29 AM, Adam R. Maxwell wrote:
> >
> >> On Sep 24, 2007, at 07:50, Christiaan Hofman wrote:
> >>
> >>> I see many problems with the file references.
> >>> - Files may not exist (especially when shared between different
> >>> computers).
> >>> - Files may be deleted/moved to trash/replaced
> >>>
> >>> So certainly the current BDSKFile objects are not sufficient.
> >>> Somehow
> >>> a non-existing file should remember the aliasdata for saving, and an
> >>> existing file should remember a (relative?) path in case it's
> >>> removed. I think we need a subclass of BDSKFSRefFile and
> >>> BDSKURLFile.
> >>
> >> I think a broken alias is expected behavior if the file is deleted,
> >> and I'm not convinced that accounting for it with a path is
> >> necessarily an improvement...I wonder what happens with the FSRef in
> >> that case, though? Watching it with the FSEvent stuff in Leopard
> >> would be the most useful approach, but again it's a lot of work for
> >> an
> >> edge case.
> >>
> >
> > I do think that people expect that when you replace a file (by
> > deleting one and adding another one in the same place), for example
> > using a script, keeps the linked file. I think the FSRef becomes
> > invalid in that case (though I'm not sure). If you look at NSDocument
> > (which uses FSRef) you see that when you delete the file, the proxy
> > icon is lost, while if you move the file the proxy icon is changed.
> >
> >> I definitely agree that if the file isn't present when the file
> >> object
> >> is instantiated, the alias/path that was used to instantiate it
> >> should
> >> be preserved. I thought that could be handled with a subclass of
> >> BDSKFile that's similar to BDSKURLFile (or replace it).
> >>
> >
> > That's possible. I'm not sure if it should be an alias+relative path
> > or alias+URL(absolute path).
>
> I've been doing a bit of homework trying to figure out what the
> relative path features in BDAlias can do. It turns out that aliases
> store a path, and will try that first before using file ID. There's a
> long thread about this at <
> http://www.cocoabuilder.com/archive/message/cocoa/2004/8/19/114982
> >, and it's documented at <
> http://developer.apple.com/technotes/tn2002/tn2053.html#TN001072
> >.
>
> Also, relative path aliases seem to work across systems, but I have to
> figure out if we can use this; I'm just mentioning it for now. Test
> code at the end of this message. I created an aliasData file on
> machine 1, then set up the same relative path structure on machine 2
> (../testDir/testFile) and copied the aliasData from machine 1 to
> machine 2. The second call using fullPathRelativeToPath: worked on
> machine 2 using the alias data created on machine 1.
>
> So we may be doing some unnecessary work by storing paths. Also, a
> file that's deleted would be resolved correctly using the original
> alias data, although you're right that FSRefs become invalid in that
> case.
That's nice, didn't know that. So it seems we should keep an FSRef and an
alias. If the FSRef doesn't work, we try to re-resolve the alias. The alias
can also be used as a fall-back for saving.
What happens when the document location changes (such as in save as)? Should
the aliases be updated, perhaps with a notifications? Also for saving we
need to be careful, especially for Save As and Export, as the base path is
generally different. So the bibtexData method needs to know the location
where the file will be saved to, and encode the proper aliases.
Also does is an alias with a relative path able to also find back an
absolute path?
Still don't see how to handle new documents.
>>> Also the base path is a problem. For new databases there may not
> >>> be a
> >>> filename. And what is the base path for export/save as? And how is
> >>> it
> >>> passed to the file objects?
> >>
> >> It would have to be passed by the BibItem when saving, since it's the
> >> only object that connects the document and files.
> >>
> >
> > But how does BibItem know the filename?
>
> [[[self document] fileURL] path]...but it may not be available at that
> point in the save cycle.
>
> >>> But what about initially adding items to a new database? I think
> >>> they
> >>> should be represented by an FSRef and an absolute path (so the path
> >>> in the new BDSKFile subclass should be absolute, or both relative
> >>> and
> >>> absolute).
> >>
> >> Why a path as well as FSRef? For the trashing case?
> >
> > Yes. Otherwise deleting the file will give a BDSKFile object with
> > absolutely no information.
>
> So maybe we should just create new ones with a BDAlias ivar
> immediately, since those should work around the deletion problem?
>
> --
> adam
As I said above we should always keep the alias, at least as data, in the
BDSKFile object. I'm not sure if the BDAlias object is needed or useful.
Basically, the question is also if an alias created with a relative path is
able to resolve the absolute path, in case the relative path becomes
invalid. Then this would be sufficient.
However we may want to copy items with files between documents. If the file
does not exist, can the path still be determined from the alias? Note that
we pass archived items, which archive the path. Perhaps they should also
archive the alias data. Anyway, as the base paths differ, they should be
able to refer to the file using absolute path, so that should work. If
aliases can handle that, it would be OK to pass the alias data instead of
the full path.
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
