On Jan 1, 2008, at 3:08 PM, Christiaan Hofman wrote: > > On 1 Jan 2008, at 11:54 PM, Adam R. Maxwell wrote: > >> >> On Jan 1, 2008, at 1:02 PM, Christiaan Hofman wrote: >> >>> >>> On 1 Jan 2008, at 9:43 PM, Adam R. Maxwell wrote: >>> >>>> On Jan 1, 2008, at 12:31 PM, Christiaan Hofman wrote: >>>> >>>>> Ho should we actually handle symlinks in linked files? Currently >>>>> we >>>>> resolve those., I'm not sure if that's correct. It's inconsistent >>>>> with aliases. >>>> >>>> After your last message, I've been wondering the same thing myself. >>>> Right now I'm not sure we're consistent even with aliases. IIRC we >>>> were resolving aliases for icons which was probably wrong. >>> >>> No, only in the parent (if I understand you correctly). >> >> I was thinking of -[BibItem imageForURLField:] which resolves aliases >> to see if a file is missing. If an alias file exists, it's not >> really >> missing...but it's useless unless the target exists. >> >>>> I think >>>> the NSWorkspace UTI resolution method shouldn't resolve aliases by >>>> default, either, but there was probably some reason for doing it >>>> that >>>> way. Maybe for sorting URLs. >>>> >>>> I guess the question is what we should move, the link (symlink or >>>> alias) or the target file? I suppose moving the link is the >>>> correct >>>> thing to do. >>>> >>> >>> That's the way we implemented BDSKFiler. >>> >>>>> This applies both to whether the linked file is a >>>>> symlink or the document. Though perhaps the document URL is always >>>>> resolved? Also I'm not sure whether aliases resolve symlinks or >>>>> could >>>>> keep aliases to a symlink. Certainly not resolving symlinks >>>>> means we >>>>> can't use BDAlias, as it uses the wrong methods to create FSRefs. >>>> >>>> It looks like an alias to a symlink works in Finder, although >>>> that's >>>> kind of gross. >>> >>> >>> For what it's worth, the document's URL is also always resolved. I >>> don't know about aliases pointing to symlinks or aliases, is that >>> possible? For FSRef we need to use FSPathMakeRefWithOptions to get >>> an >>> FSRef to pointing to a symlink (instead of CFURLGetFSRef). >> >> I think everything we get from Cocoa is guaranteed to be resolved >> (from NSOpenPanel/NSSavePanel or NSDocument). > > So it's impossible to choose an alias or symlink file using > NSOpenPanel?
Apple is supposed to return the resolved path if there's an alias or symlink in the middle of it, but I'm not sure what happens when you choose an alias file or symlink as the target. This is the post I was thinking of: http://www.cocoabuilder.com/archive/message/cocoa/2007/9/5/188782 >> The alias pointing to a >> symlink probably needs to be resolved recursively >> (FSResolveAliasFileWithMountFlags doesn't seem to work), but aliases >> pointing to aliases appear to work. > > What do you mean it doesn't work? It retruns an error? Or does it > return the symlink? And what do you mean with work? Dp you mean that > an alias pointing to an alias file resolves to the target of the > alias file? Ignore that; it does work (alias file pointing to alias file resolves to target, and alias file pointing to symlink resolves to target). -- adam ------------------------------------------------------------------------- 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
