This has nothing to do with Core Data. Finder aliases are not
resolved automatically in the same way that symbolic links are;
they need to be resolved manually using the Carbon File Manager.
This is not normally a problem as only manually-typed paths are
likely to contain elements that are Finder aliases; paths returned
by NSOpenPanel or NSSavePanel won't.
Well, it _is_ an problem which is still unresolved after some years
of OS X.
- the Finder offers no UI for creating anything (hard- or symlinks)
besides than alias files
- paths are used everywhere in Cocoa Apps
- when the User reorganises his harddisk (duh, my iTunes Lib and
CoolApp Lib folders are too huge, I move them to /BigExternalStorage/
Overflow and place that "Make Alias" thingy in the original location)
- as the perceived mantra is "Wonderful Cocoa supercedes Carbon" I'd
expect [aNSString stringByExpandingTildeInPath] also takes care of
alias files along the way
- it depends entirely on how interested in that "bad" Carbon API the
author of CoolApp was if the User gets broken or working behavior.
Regards,
Tom"IIRC filing an bug against this which once again went into the
Radar dustbin"E
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
