On 19/01/2013, at 1:21 AM, Christiaan Hofman <[email protected]> wrote:
> > On Jan 18, 2013, at 15:02, Graham Dennis wrote: > >> >> On 19/01/2013, at 12:36 AM, "Adam R. Maxwell" <[email protected]> wrote: >> >>> >>> On Jan 18, 2013, at 04:56 , Christiaan Hofman <[email protected]> wrote: >>> >>>> On Jan 18, 2013, at 13:35, Graham Dennis wrote: >>>> >>>>> Apart from my problem that the current behaviour leads to problems >>>>> specifically with Dropbox, which file the link is resolved to depends >>>>> upon whether BibDesk is running and has previously resolved a link when >>>>> the user moves the file and creates a new one. >>>> >>>>> >>>>> So, for the situation proposed earlier where file ~/foobar.pdf is moved >>>>> to ~/Documents/foobar2013.pdf and a new ~/foobar.pdf is created, what >>>>> should happen if >>>>> 1) BibDesk was open before changes, and ~/foobar.pdf had been resolved >>>>> into an FSRef and >>>>> 2) if BibDesk was not open during the changes? >>>>> >>>>> My opinion is that the behaviour in both cases should be the same to >>>>> avoid user confusion. Do you agree / disagree? >>>>> >>>>> Thanks, >>>>> Graham >>>> >>>> >>>> It is not possible to have the same behavior in all cases. So this point >>>> is basically mute. (My point is *not* that it cannot behave the same way >>>> in this particular situation, but more generally.) The point is that if >>>> you fix it for some specific case, it will go wrong for some other case. >>>> >>>> The main point is that one cannot distinguish between Dropbox moving a >>>> file, and the user moving a file. >>> >>> Indeed. We decided to use FSRef/file ID as primary, and path is a backup >>> for those as a last resort; aren't aliases still resolved by trying file ID >>> first? Changing (partially or fully) from a file ID-based system to >>> path-based would be problematic. With a path-based system, you should >>> (ideally) track file changes with kevent or FSEvents, but the former >>> doesn't work with thousands of files and the latter can only watch >>> directories. >>> >> >> The alias used by BibDesk seems to prefer the filename over the file ID. If >> I quit BibDesk, and rename a linked file and copy a new file with the same >> name as the original, BibDesk will resolve the link on next launch to the >> new file with the same name as the original, not the renamed file. >> > > > kARMNoUI | kARMSearch | kARMSearchRelFirst | kARMTryFileIDFirst, apart from > that we search the relative path first (this should not be necessary at all, > but AliasHandle does not handle relative paths properly.) > In this option list you specify both "kARMSearchRelFirst" and "kARMTryFileIDFirst". It's not obvious to me which takes precedence, and the docs don't make that clear. I did some testing on my OS X 10.8.2 system by commenting out the relative path code in -[BDSKLinkedAliasFile fileRef] which shows that in the case of a moved file and a new file with the original's name FSMatchAliasBulk returns the new file with the old filename. >> It seems to me that the problem is that the Alias is the canonical reference >> to the file, and an FSRef is used as a cache to avoid resolving the alias >> every time. The problem arises when the FSRef and the Alias point to >> different files. Ideally you would just resolve the Alias every time, but >> this is probably not a performant solution. So the next best thing you can >> do is to determine when the cache is invalid and re-resolve it. > > A problem is: when, and how do you (i.e. the program) decide that? > > Pulling in lastURL is not an option. It's already complex enough as it is, > based on relativePath, alias, and fileRef. Moreover, lastURL is not properly > (automatically) updated. It makes it more complex and more fragile. Note we > only update the fileRef when we already know it's invalid. Not when we think > there may (or may not) exist a better alternative, even we would decide it > would be a better alternative (and I'm not convinced even on that). That only > makes it more fragile, because we could be wrong. As always, losing a file is > far more a problem than getting a different file the user may not always > expect. > Ignoring for the moment any performance issues, if a new call to -[BDSKLinkedFileAlias fileRef] (or equivalently, quitting and re-opening BibDesk) will resolve a different file than the current "fileRef" ivar, should the "fileRef" ivar be considered out of date? This seems to be the core of my question. I think it should be considered out of date, but my impression is that others may disagree. If it is, then I would suggest a solution that checks for conditions when -[BDSKLinkedFileAlias fileRef] might change, and then call that method again to obtain the canonical reference. If no such file is found, then we would keep the old file reference. Christiaan has suggested that it is (or may be) possible for -[BDSKLinkedFileAlias fileRef] to not return a file even if we previously had an FSRef. I'm confused as to how this might happen because the AliasHandle will (presumably) contain the information for the FSRef, so if the previous FSRef still exists, then there is at least one candidate file that FSMatchAliasBulk could return. That said, being a little paranoid is a good thing. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
