On Jan 18, 2013, at 17:03, Christiaan Hofman <[email protected]> wrote:
> On Jan 18, 2013, at 15:52, Colin A. Smith wrote: > >> Here's a possible solution to the Dropbox problem (at least as Dropbox >> currently works): slightly expand the conditions upon which a fileRef is >> invalid. A fileRef could be considered invalid not only if it couldn't be >> resolved, but also if it resolves to a file that has an ancestor directory >> that starts with a dot. This would also address the possible case of a user >> manually moving a linked file to the Trash (i.e. ~/.Trash), then replacing >> it with a new file of the same name in the original location. If I were a >> user, I'd expect BibDesk to link to the new file, not the old file sitting >> in the Trash. >> >> Cheers. >> >> -Colin > > You fail to appreciate the pont. The point is that we update the fileRef only > when we are forced to update because it is already garbage. We won't update > it when we may not like where it point to for some reason. Because that could > mean that we end up pointing nowhere. > > Christiaan I don't think fileRef should be updated unless basePath/relativePath also points to a legitimate file, so pointing nowhere wouldn't happen. I totally agree that pointing nowhere should be avoided as much as possible, and as you said previously, "As always, losing a file is far more a problem than getting a different file the user may not always expect." The problem is, prioritizing the file that fileRef points to over the file that basePath/relativePath points to will actually increase the likelihood of that happening in the future if the file is moved to .Trash or .dropbox.cache. As soon as either .Trash or .dropbox.cache is purged, we point to nowhere. I can understand concerns about making BibDesk more fragile, especially for users that have always used it with standard filesystems and will continue to do so. However, it appears that more and more users are embracing Dropbox as a method to store their *.bib files and linked files. For them, I think it would be helpful to at least provide a hidden preference that would trigger slightly modified linked file handling. An alternative could be to start another fork of BibDesk that provides this functionality, but I think it's really unfortunate when that happens. Cheers. -Colin ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
