On 2 Jan 2008, at 1:35 AM, Adam R. Maxwell wrote: > > 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
I would then say that it doesn't work, because it makes it impossible to store an alias pointing to an alias (or symlink) if we want to. Christiaan ------------------------------------------------------------------------- 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
