On 19/01/2013, at 9:08 AM, Christiaan Hofman <[email protected]> wrote:
> > On Jan 18, 2013, at 21:59, Graham Dennis wrote: > >> >> 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. >> > > Again, different *from what*? The thing is, that we have the fileRef to track > the file while BibDesk is running. The rest is for safety, persistency, or > UI. So not the primary link. And the fileRef is always the same as the > fileRef. The URL is, as I have said a few times, not reliable. While > resolving the alias every time is defeating the purpose of the fileRef, and > is a big performance issue (which cannot be ignored). This makes the rest of > the paragraph basically irrelevant. THe last part is therefore secondary to > the question: what is the reliable and efficient link. That is the fileRef. > At any time, the -[BDSKLinkedAliasFile fileRef] method can be called. The result of this method is not necessarily the same as the "fileRef" ivar. This is what I mean as different. I understand that URLs are not reliable. I'm not suggesting using them to replace FSRef's or aliases. I'm suggesting using the fact that the URL has changed as an indication that the "fileRef" ivar may not be the same FSRef as would be returned from "-[BDSKLinkedAliasFile fileRef]". My suggested code of course would not resolve the alias every time for performance reasons, but would call "-[BDSKLinkedAliasFile fileRef]" only on the infrequent occasions that the URL changed. I am here making the assumption that the URL will change only as a result of user action and that the result of CFURLCreateFromFSRef is not flaky and returns different URLs at random. So performance-wise, the alias would only be resolved as a result of user action, in which case accuracy (I would argue) is more important than speed. It seems the disagreement is that you consider the FSRef that the Alias is first resolved to to be the canonical reference to the file so long as it remains valid, even though it is the Alias that is persisted to disk and would be used on subsequent launches. 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
