Hi,
>> When BibDesk next asks for the URL for the file, BibDesk resolves the URL
>> from the FSRef instead of the alias. The FSRef now points to the PDF in
>> Dropbox's private cache. (This happens in -[BSDKLinkedAliasFile URL]).
>>
>> My proposed solution is to notice if the URL has moved, and re-resolve the
>> alias in this case. This causes the correct file to be resolved. I've
>> attached a patch which corrects this problem.
>
> I'm not entirely in favor of this, as it seems like a pretty big change from
> existing behavior. Suppose you have a reference with linked file at
> ~/foobar.pdf. With BibDesk running, you can move that file in Finder to
> ~/Documents/foobar2013.pdf, and BibDesk should track it. Suppose you then
> create another file at ~/foobar.pdf. If I recall the BD design correctly, the
> reference should point to ~/Documents/foobar2013.pdf, whereas with your patch
> it sounds like it would point to ~/foobar.pdf?
>
If you just move ~/foobar.pdf to ~/Documents/foobar2013.pdf and return to
BibDesk, then with my patch BibDesk updates the link to point to
~/Documents/foobar2013.pdf (because the alias resolves to this file).
If the user moved ~/foobar.pdf *and* created a new file in its place before
switching back to BibDesk, it's not obvious to me which file the user desires
the link to resolve to. However with the current design, different things
happen depending on whether or not BibDesk had resolved ~/foobar.pdf before
you moved it. If you had ~/foobar.pdf resolved in BibDesk to an FSRef, then
move the file and create a new file, and then return to BibDesk, you'll end up
with a link to ~/Documents/foobar2013.pdf. However, if you didn't have BibDesk
running, then when you launch BibDesk at the end the alias will be resolved to
~/foobar.pdf not ~/Documents/foobar2013.pdf. My patch makes the behaviour the
same in both cases (the latter behaviour).
> Part of the point of using FSRefs is that you avoid mucking about with
> fragile path comparisons, so that makes me a bit nervous too. In fact,
> -[NSURL isEqual:] will actually fail (or at least it used to) by returning NO
> for the same URL returned from different APIs.
>
I wasn't aware of this. I think it's OK in this situation because lastURL is
simply the last value of aURL, and hence both are obtained from
CFURLCreateFromFSRef().
The full (patched) method implementation looks like:
- (NSURL *)URL;
{
BOOL hadFileRef = fileRef != NULL;
CFURLRef aURL = (hadFileRef || [self fileRef]) ? CFURLCreateFromFSRef(NULL,
fileRef) : NULL;
BOOL moved = [(NSURL *)aURL isEqual:lastURL] == NO && (aURL != NULL &&
lastURL != nil);
if ((aURL == NULL || moved) && hadFileRef) {
// fileRef was invalid, or URL moved, try to update it
[self setFileRef:NULL];
if ([self fileRef] != NULL)
aURL = CFURLCreateFromFSRef(NULL, fileRef);
}
BOOL changed = [(NSURL *)aURL isEqual:lastURL] == NO && (aURL != NULL ||
lastURL != nil);
if (changed) {
[lastURL release];
lastURL = [(NSURL *)aURL retain];
if (isInitial == NO)
[delegate performSelector:@selector(linkedFileURLChanged:)
withObject:self afterDelay:0.0];
}
isInitial = NO;
return [(NSURL *)aURL autorelease];
}
Note that -[NSURL isEqual:] was previously used by this method in the BOOL
changed = ... line, which I haven't modified.
> If the idea is to add a workaround specifically for Dropbox, do they
> guarantee anything about the location? Will it always be under
> ~/Dropbox/.dropbox.cache? Hitting the filesystem or comparing URLs is pretty
> slow, though...your way might be the only one, but it would be nice to
> understand the implications.
The idea is a workaround specifically for Dropbox, but I wanted to avoid
relying on the current behaviour of Dropbox. They don't guarantee that the
cache will be in path_to_dropbox/.dropbox.cache, and certainly your dropbox can
be located in a different location from ~/Dropbox.
As for hitting the filesystem, we're already doing that in
CFURLCreateFromFSRef, and the addition filesystem hit will be limited to the
infrequent occasions when the file has moved.
Let me know if you have any concerns or suggestions.
Regards,
Graham------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
