On Jan 1, 2008, at 4:40 PM, Christiaan Hofman wrote: > > On 2 Jan 2008, at 1:27 AM, Adam R. Maxwell wrote: > >> >> On Jan 1, 2008, at 3:59 PM, Christiaan Hofman wrote: >> >>> An inconsistency. -[NSFileManager displayNameAtPath:] returns the >>> file name of the target for a symlink. So I don't think we should >>> use >>> that now. >> >> That sounds like a bug in NSFileManager, and I don't see it here. I >> have ~/Desktop/symlink2.bib->~/Desktop/navier.bib, and it shows up as >> symlink2.bib. What does LSCopyDisplayNameForURL return? >> > > That works.
Okay, I just changed it. I wonder what to do with the file migration controller? >>> Also, we could change the "if" in FVIcon line 185 to a while loop, >>> and a similar thing to get the resolved URL. >> >> I don't think we need to. The problem I saw with an alias file- >>> symlink->target not being resolved was caused by me assigning too >> late in FVTextIcon. Or would that do something else? >> >> FWIW, LSCopyItemAttribute is documented to set the value returned by >> reference to NULL if the call fails (though I agree it's better to be >> explicit about it). >> >> -- >> adam > > That's pretty stupid, I think. It can be convenient, but it's unexpected in some cases (and you'd have to copy the old value if you care about it). LS also has the "Get" functions that return a URL copy, which is annoying as well. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
