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. > >> 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
There seems to be a more serious problem. Relative paths don't seem to work at all. At least, I'm unable to make it work. I did the following: 1. create a file and add an item linking to it using BDSKAliasFile 2. save and close 3. delete the file on disk 4. restore the file on disk 5. move the file and the saved doc to another directory (keeping the same relative location). 6. open the doc It will not be able to find the moved linked file. Without 3&4 it can find it, but that's because it finds it using the file node. Also it can found the file at the old location (through absolute path). But not through the relative path. 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
