On Tuesday, October 23, 2007, at 11:42AM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: >On 10/23/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote: >> >> >> On Tuesday, October 23, 2007, at 11:15AM, "Christiaan Hofman" < >> [EMAIL PROTECTED]> wrote: >> >I am confused about aliases to files that do not exist. This may give >> >problems for persistency of the new file objects. >> > >> >If a file does not exist, it seems that the data from the alias >> >becomes invalid. That is, if you save this data, and later try to >> >reopen it when the file has been restored on the proper path, it >> >won't be able to find this new file. >> > >> >Any idea why this would happen, and how to avoid this problem? >> >> So the file existed when the alias was created, and was then removed, and >> the alias data was saved? If the alias was created with a relative path (or >> the absolute path didn't change), my understanding is that the original >> alias data would be valid. Trying to resolve the alias and update it >> between the time when the file was removed and the point at which it was >> saved could probably mess it up, though. > > >I think that is indeed the problem: when the alias is resolved, the alias is >updated by FSResolveAlias. The bad thing is that it apparently updates when >resolving the alias fails. I do think that is a bug.
Is that used when the FSRef fails, then? I honestly haven't looked at the code in great detail, other than verifying that it works in my trivial test situations. The alias updating is kind of weird. >I think we need to look into unit tests or something similar for this, and >> add test scenarios as we think of them. The problems are complex with >> relative paths, and the existing alias documentation isn't as helpful as it >> could be. >> >> -- >> adam > > >The docs are certainly lacking. Moreover there can always be bugs. I may >have found a fix for this problem, by not using FSResolveAlias but rather >FSMatchAlias, and update the alias ourselves when we are sure things are OK. >And we sure should do some unit testing for different scenarios. > >Sorry for all the bugs I introduced recently. But it's almost impossible to >switch between different versions of the same project on a single computer. No apology necessary; thanks for all the work on my half-baked idea! I'm juggling two operating systems and two BibDesk source trees, which makes for some really interesting combinations :). In my local Bibdesk.xcodeproj I've removed all external dependencies for one of the trees, so I don't have to suffer through a framework rebuild every time I compile the app. I suppose changing the app name for the branch would work, but then LS and AppleScript will likely crap out. -- adam ------------------------------------------------------------------------- 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
