CoreData - cannot load .sqlstore if path contains Alias folder

  • I can't open a CoreData sqlstore if the path being used contains an
    Alias folder.  So for example, if I create an NSURL from:
    ~/Library/Application Support/TORRES/sample.sqlstore
    ...where TORRES is an Alias folder, then the following code:

    coordinator = [[NSPersistentStoreCoordinator alloc]
    initWithManagedObjectModel: [self managedObjectModel]];
    id store = [coordinator addPersistentStoreWithType:NSSQLiteStoreType
    configuration:nil URL:url options:nil error:&error];

    ... will return an error:
    The file could not be opened because the file name "TORRES" is invalid.

    Anybody else come across this?  I suppose I could check the path for
    alias folders, and resolve them, but this seems like extra work.
    Surely the CoreData loading functions would traverse the paths
    correctly?

    Regards,
    Simon
  • On Sep 5, 2007, at 7:41 AM, Simon Liu wrote:

    > Anybody else come across this?  I suppose I could check the path for
    > alias folders, and resolve them, but this seems like extra work.
    > Surely the CoreData loading functions would traverse the paths
    > correctly?

    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.

      -- Chris
  • Chris,

    Is there a quick way to resolve all the aliases in a given path,
    checking all path components?  Any 3rd party classes?  I could write
    some code using FSResolveAliasFile() but I imagine somebody has
    already done this...

    BTW: I tried BDAlias -initWithPath: and that fails - I guess it needs
    a fully resolved posix path?

    --Simon

    > 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.
    >
    > -- Chris
    >
    >
  • On Sep 5, 2007, at 12:20 PM, Simon Liu wrote:

    > Is there a quick way to resolve all the aliases in a given path,
    > checking all path components?  Any 3rd party classes?  I could write
    > some code using FSResolveAliasFile() but I imagine somebody has
    > already done this...

    I don't know of any third-party categories on NSString or classes to
    do it.  You'll have to walk the path components using the methods in
    <Foundation/NSPathUtilities.h> and resolve any Finder alias files you
    come across yourself.

    Again, though, generally speaking it should be *hard* to wind up with
    a path in your application that happens to traverse a Finder alias
    file.  If you get a path from NSOpenPanel or NSSavePanel, that path
    should already be resolved - no Finder alias file resolution necessary.

    If you are storing a path in your user defaults it's possible that the
    user could replace a component with a Finder alias file; in that case,
    however, instead of a bare path you should really be storing an alias
    record (using BDAlias, NDAlias, or the like) in your user defaults.
    When you resolve that alias record to a path, the path will be fully-
    resolved and not one that tries to traverse Finder alias files.

    > BTW: I tried BDAlias -initWithPath: and that fails - I guess it needs
    > a fully resolved posix path?

    The BDAlias class is used to represent alias records, not Finder alias
    files (which are a way of serializing alias records).  Thus trying to
    initialize a BDAlias instance from a path that traverses an alias will
    have the same problem as trying to traverse that path in any other
    fashion.

      -- Chris
  • > If you are storing a path in your user defaults it's possible that the
    > user could replace a component with a Finder alias file; in that case,
    > however, instead of a bare path you should really be storing an alias
    > record (using BDAlias, NDAlias, or the like) in your user defaults.
    > When you resolve that alias record to a path, the path will be fully-
    > resolved and not one that tries to traverse Finder alias files.

    Thanks for the detailed reply.  I think this was discussed before, but
    just for clarification w/regards to BDAlias: if a user moves a
    file/folder (which we have based a BDAlias upon and stored in
    defaults), and in its original place creates a new file/folder with
    the same name, which one will BDAlias resolve to, when restored from
    defaults?  The original moved item, or the newly created one?  Does
    BDAlias resolve a path first, and if invalid, then resolve its Alias
    record?
  • On Sep 5, 2007, at 4:29 PM, Simon Liu wrote:

    > Thanks for the detailed reply.  I think this was discussed before, but
    > just for clarification w/regards to BDAlias: if a user moves a
    > file/folder (which we have based a BDAlias upon and stored in
    > defaults), and in its original place creates a new file/folder with
    > the same name, which one will BDAlias resolve to, when restored from
    > defaults?  The original moved item, or the newly created one?  Does
    > BDAlias resolve a path first, and if invalid, then resolve its Alias
    > record?

    The BDAlias class is not special, it doesn't do any special-case
    handling of paths versus alias records or anything like that; it just
    represents an alias record.  And it just calls through to the Carbon
    Alias Manager to resolve the alias record it represents when asked.
    You can see that from its source code.

    So the answer is that it will do whatever the Carbon Alias Manager
    does, which has differed on different on different versions of the
    operating system.  Mac OS X 10.2 and later (and System 7 through Mac
    OS 9.2.2) check the path embedded in the alias record first when
    resolving aliases, while Mac OS X 10.0 and 10.1 checked the file ID
    first.  See this thread from 5+ years ago for details and history <http://lists.apple.com/archives/cocoa-dev/2002/Aug/msg01826.html>.

      -- Chris
  • On 05.09.2007, at 21:07, Chris Hanson wrote:

    > 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
  • On Sep 6, 2007, at 12:27 AM, Thomas Engelmeier wrote:

    > 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

    <PLUG STYLE="shameless">
    I wrote a CM plugin that fixes this problem: <http://
    seiryu.home.comcast.net/symboliclinker.html>
    </PLUG>

    Nick Zitzmann
    <http://www.chronosnet.com/>
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today