On 23 Oct 2007, at 8:51 PM, Adam R. Maxwell wrote: > > 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. >
We were using FSResolveAlias to resolve the alias, so before we know wether the FSRef can be constructed. That is changed now. I haven't tested it though. >> 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 It is certainly annoying. Christiaan ------------------------------------------------------------------------- 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
