How do I get a file reference w/o relying on the path?

  • I want to store a reference to a file in an ivar that will allow the user to change the file's name and/or the directory (i.e. the path) and still allow me to access it.  I don't want to create a file (like an ailas).  I need to store the file reference in a variable so I can open the file no matter where the user moves it or renames it.

    For those of you who know REALbasic I can do this easily with FolderItem.GetSaveInfo.

    How can I do this in Cocoa?

    Thanks
  • On Apr 3, 2010, at 5:20 PM, Brad Stone wrote:

    > I want to store a reference to a file in an ivar that will allow the user to change the file's name and/or the directory (i.e. the path) and still allow me to access it.  I don't want to create a file (like an ailas).  I need to store the file reference in a variable so I can open the file no matter where the user moves it or renames it.

    FSRefs have the property you desire.  As of Snow Leopard, though, the new recommended technique is to use a file reference NSURL.  Check the NSURL documentation and also:

    http://developer.apple.com/mac/library/documentation/cocoa/conceptual/LowLe
    velFileMgmt/Articles/FileManagementNSURL.html


    Note that an alias _record_ is different from an alias _file_.  An alias record is data in memory and is suitable for this purpose, but perhaps overkill.

    As of Snow Leopard, alias records are deprecated in favor of bookmark data, but, again, it's probably overkill.  (Both alias records and bookmark data are more suitable if the reference is to be persisted for use by a later process.  Also, both can apply more robust searching heuristics to find an appropriate file even if it isn't the original.  For example, if the original is deleted and replaced with a new file of the same name.)

    Cheers,
    Ken
  • Very interesting.  According to the documentation if I want to store the reference and want it to persist after a reboot I need to do a bookmark.

    You should not store or archive file reference URLs. A file’s ID may be different for different boots of the operating system. If you need to store a URL, see “Working with Bookmarks and Aliases.”
    THANK YOU so much for pointing me in the correct direction.

    On Apr 3, 2010, at 6:55 PM, Ken Thomases wrote:

    > On Apr 3, 2010, at 5:20 PM, Brad Stone wrote:
    >
    >> I want to store a reference to a file in an ivar that will allow the user to change the file's name and/or the directory (i.e. the path) and still allow me to access it.  I don't want to create a file (like an ailas).  I need to store the file reference in a variable so I can open the file no matter where the user moves it or renames it.
    >
    > FSRefs have the property you desire.  As of Snow Leopard, though, the new recommended technique is to use a file reference NSURL.  Check the NSURL documentation and also:
    >
    > http://developer.apple.com/mac/library/documentation/cocoa/conceptual/LowLe
    velFileMgmt/Articles/FileManagementNSURL.html

    >
    >
    > Note that an alias _record_ is different from an alias _file_.  An alias record is data in memory and is suitable for this purpose, but perhaps overkill.
    >
    > As of Snow Leopard, alias records are deprecated in favor of bookmark data, but, again, it's probably overkill.  (Both alias records and bookmark data are more suitable if the reference is to be persisted for use by a later process.  Also, both can apply more robust searching heuristics to find an appropriate file even if it isn't the original.  For example, if the original is deleted and replaced with a new file of the same name.)
    >
    > Cheers,
    > Ken
    >
  • Ken, he asked for a reference that wouldn't break if the file were moved or renamed. Neither FSrefs nor URLs have that property.

    Brad, what you want is a bookmark (in 10.6) or an alias reference. Aliases didn't have a Cocoa API until 10.6, but the procedural API isn't hard to use.

    --Jens {via iPad}

    On Apr 3, 2010, at 3:55 PM, Ken Thomases <ken...> wrote:

    > On Apr 3, 2010, at 5:20 PM, Brad Stone wrote:
    >
    >> I want to store a reference to a file in an ivar that will allow the user to change the file's name and/or the directory (i.e. the path) and still allow me to access it.  I don't want to create a file (like an ailas).  I need to store the file reference in a variable so I can open the file no matter where the user moves it or renames it.
    >
    > FSRefs have the property you desire.  As of Snow Leopard, though, the new recommended technique is to use a file reference NSURL.  Check the NSURL documentation and also:
    >
    > http://developer.apple.com/mac/library/documentation/cocoa/conceptual/LowLe
    velFileMgmt/Articles/FileManagementNSURL.html

    >
    >
    > Note that an alias _record_ is different from an alias _file_.  An alias record is data in memory and is suitable for this purpose, but perhaps overkill.
    >
    > As of Snow Leopard, alias records are deprecated in favor of bookmark data, but, again, it's probably overkill.  (Both alias records and bookmark data are more suitable if the reference is to be persisted for use by a later process.  Also, both can apply more robust searching heuristics to find an appropriate file even if it isn't the original.  For example, if the original is deleted and replaced with a new file of the same name.)
    >
    > Cheers,
    > Ken
  • On Apr 3, 2010, at 8:31 PM, Jens Alfke wrote:

    > Ken, he asked for a reference that wouldn't break if the file were moved or renamed. Neither FSrefs nor URLs have that property.

    Yes, they do.

    From the link I gave <http://developer.apple.com/mac/library/documentation/cocoa/conceptual/LowLe
    velFileMgmt/Articles/FileManagementNSURL.html
    >:

    "File reference URLs provide a way to track a file by its ID. This means that the reference is valid even if the file’s name or location in the file system changes."

    File reference URLs are new with Snow Leopard.  Check out the release notes and "What's New in Mac OS X: Mac OS X 10.6" to learn about them.

    And FSRefs have always had this property.  Adding file reference URLs was essentially a way of allowing URLs to provide analogous functionality as FSRefs.

    Regards,
    Ken
  • Ken Thomases <ken...> wrote:

    > As of Snow Leopard, alias records are deprecated in favor of bookmark data, but, again, it's probably overkill.  (Both alias records and bookmark data are more suitable if the reference is to be persisted for use by a later process.  Also, both can apply more robust searching heuristics to find an appropriate file even if it isn't the original.  For example, if the original is deleted and replaced with a new file of the same name.)

    Having missed the introduction of the new bookmark routines, and having not gotten any warnings in my code, I was a bit surprised to read that alias records are deprecated. From a quick scan, it looks like the bookmark methods are wrappers around the alias manager with (after about 20 years) an official mechanism for creating Finder alias files.
    G
  • On Apr 4, 2010, at 12:06 PM, Gregory Weston wrote:

    > Ken Thomases <ken...> wrote:
    >
    >> As of Snow Leopard, alias records are deprecated in favor of bookmark data, but, again, it's probably overkill.  (Both alias records and bookmark data are more suitable if the reference is to be persisted for use by a later process.  Also, both can apply more robust searching heuristics to find an appropriate file even if it isn't the original.  For example, if the original is deleted and replaced with a new file of the same name.)
    >
    > Having missed the introduction of the new bookmark routines, and having not gotten any warnings in my code, I was a bit surprised to read that alias records are deprecated.

    Sorry.  I probably shouldn't have said "deprecated".  Aliases are not officially deprecated, as far as I know.  Perhaps "superseded" is a better word.  Bookmarks are clearly the new Apple-preferred way of achieving what used to be done with aliases.

    > From a quick scan, it looks like the bookmark methods are wrappers around the alias manager with (after about 20 years) an official mechanism for creating Finder alias files.

    Well, conceptually, bookmarks are a superset of alias records.  However, I believe that they have separate representations.  In particular, some of the documentation mentions that alias files created using the bookmark API contain both the bookmark data and the old-style alias record, separately.

    Also, bookmark data records some of the file properties so you can query them without having to resolve or access the original file.

    Regards,
    Ken
  • You're saying that if I have a FSRef to a file, then the file is moved, the FSRef will still reference the moved file and not the location where it used to be?

    That's surprising to me, because FSRefs were created as a replacement for FSSpecs, which do not have that property (they were a struct {volume ID, dir ID, filename}.)

    Anyway, note that a file inode ID is more fragile than an alias/bookmark, because it won't survive the common practice of replacing an old copy of a file with a new one ("safe save") unless the code doing the replace is careful to propagate metadata to the new file.

    --Jens {via iPad}

    On Apr 4, 2010, at 8:00 AM, Ken Thomases <ken...> wrote:

    > On Apr 3, 2010, at 8:31 PM, Jens Alfke wrote:
    >
    >> Ken, he asked for a reference that wouldn't break if the file were moved or renamed. Neither FSrefs nor URLs have that property.
    >
    > Yes, they do.
    >
    > From the link I gave <http://developer.apple.com/mac/library/documentation/cocoa/conceptual/LowLe
    velFileMgmt/Articles/FileManagementNSURL.html
    >:
    >
    > "File reference URLs provide a way to track a file by its ID. This means that the reference is valid even if the file’s name or location in the file system changes."
    >
    > File reference URLs are new with Snow Leopard.  Check out the release notes and "What's New in Mac OS X: Mac OS X 10.6" to learn about them.
    >
    > And FSRefs have always had this property.  Adding file reference URLs was essentially a way of allowing URLs to provide analogous functionality as FSRefs.
    >
    > Regards,
    > Ken
    >
  • On Apr 4, 2010, at 12:50 PM, Jens Alfke wrote:

    > You're saying that if I have a FSRef to a file, then the file is moved, the FSRef will still reference the moved file and not the location where it used to be?

    Yes.  They are file-ID-based.

    > That's surprising to me, because FSRefs were created as a replacement for FSSpecs, which do not have that property (they were a struct {volume ID, dir ID, filename}.)

    True, although FSSpecs should have tracked the parent directory should it have been moved or renamed.  I'm not sure they did, though.

    Also, remember that, unlike FSSpecs, FSRefs can only refer to existing files/directories -- precisely because they are file-ID-based.

    It's hardly surprising that the replacement differs from the original, otherwise why replace the original?

    Cheers,
    Ken
  • On Apr 4, 2010, at 12:50 PM, Jens Alfke wrote:

    > You're saying that if I have a FSRef to a file, then the file is moved, the FSRef will still reference the moved file and not the location where it used to be?
    >
    > That's surprising to me, because FSRefs were created as a replacement for FSSpecs, which do not have that property (they were a struct {volume ID, dir ID, filename}.)
    >
    > Anyway, note that a file inode ID is more fragile than an alias/bookmark, because it won't survive the common practice of replacing an old copy of a file with a new one ("safe save") unless the code doing the replace is careful to propagate metadata to the new file.
    >
    > --Jens {via iPad}

    This is the way FSRefs work. However, AliasRecords always contained both the path *and* the file ID. I believe it used the path first, and if it didn’t find a file there, then it fell back on the file ID. There were, of course, ways to alter this default behavior, such as the kResolveAliasTryFileIDFirst flag, which reversed the default resolution behavior, and the FSNewAliasMinimal() function, which left out one of the two ways of finding the file (I think it kept the file ID and left out the path, but I could be misremembering). Anyway, I’d be pretty surprised if the new bookmark feature didn’t also include this functionality.

    By the way, it’s not the file inode ID that a FSRef points to, it’s the catalog node ID. The ID is actually a property of the catalog B-tree node rather than the file itself - if you have a file that has multiple hard links, each hard link will have the same inode but a different CNID.

    Charles
  • On Sat, 3 Apr 2010 18:31:03 -0700, Jens Alfke said:

    > Brad, what you want is a bookmark (in 10.6) or an alias reference.
    > Aliases didn't have a Cocoa API until 10.6, but the procedural API isn't
    > hard to use.

    There is the 3rd party NDAlias wrapper, which works quite well:
    <http://github.com/nathanday/ndalias>

    On Sun, 4 Apr 2010 12:28:59 -0500, Ken Thomases said:

    > Sorry.  I probably shouldn't have said "deprecated".  Aliases are not
    > officially deprecated, as far as I know.  Perhaps "superseded" is a
    > better word.

    It likely won't be deprecated for a long long time either, just like the
    Resource Manager.  Many file formats (including QuickTime's .mov) store
    aliases and so Apple needs to keep this functionality "forever".

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • Le 4 avr. 2010 à 19:50, Jens Alfke a écrit :

    > You're saying that if I have a FSRef to a file, then the file is moved, the FSRef will still reference the moved file and not the location where it used to be?
    >
    > That's surprising to me, because FSRefs were created as a replacement for FSSpecs, which do not have that property (they were a struct {volume ID, dir ID, filename}.)
    >
    > Anyway, note that a file inode ID is more fragile than an alias/bookmark, because it won't survive the common practice of replacing an old copy of a file with a new one ("safe save") unless the code doing the replace is careful to propagate metadata to the new file.

    FSExchangeObjects and exchangedata(2) do not exchange the file ID.
    The new file will have the same ID than the old one, and so, the FSRef will point on the new file automatically.

    -- Jean-Daniel
  • At 9:54 AM +0200 4/6/10, Jean-Daniel Dupas wrote:
    > Le 4 avr. 2010 à 19:50, Jens Alfke a écrit :
    >
    >> You're saying that if I have a FSRef to a file, then the file is moved, the FSRef will still reference the moved file and not the location where it used to be?
    >>
    >> That's surprising to me, because FSRefs were created as a replacement for FSSpecs, which do not have that property (they were a struct {volume ID, dir ID, filename}.)
    >>
    >> Anyway, note that a file inode ID is more fragile than an alias/bookmark, because it won't survive the common practice of replacing an old copy of a file with a new one ("safe save") unless the code doing the replace is careful to propagate metadata to the new file.
    >
    > FSExchangeObjects and exchangedata(2) do not exchange the file ID.
    > The new file will have the same ID than the old one, and so, the FSRef will point on the new file automatically.

    Unfortunately, FSRefs don't survive the common practice of manually replacing the file in the Finder. This *does* change the file id and invalidates the FSRef. I had to change to explicitly saving an AliasRecord in an NSData to keep track of a file properly.

    Jon
  • At 8:43 AM -0700 4/6/10, Jon Pugh wrote:
    > I had to change to explicitly saving an AliasRecord in an NSData to keep track of a file properly.

    I should probably clean up and share my code too.  This uses an alias relative to your home folder. The alias is stored in NSUserDefaults under the specified key. You probably want to retain or copy the path you get from loadPathFromKey since it's autoreleased or nil.

    Enjoy.

    Jon

    - (void) savePath: (NSString*) path forKey: (NSString*) key
    {
    FSRef fsFile, fsHome;
    AliasHandle aliasHandle;
    NSString* homePath = [@"~" stringByExpandingTildeInPath];
    OSStatus status = FSPathMakeRef((unsigned char*)[homePath cStringUsingEncoding: NSUTF8StringEncoding], &fsHome, NULL);
    NSAssert(status == 0, @"FSPathMakeRef fsHome failed");
    status = FSPathMakeRef((unsigned char*)[path cStringUsingEncoding: NSUTF8StringEncoding], &fsFile, NULL);
    NSAssert(status == 0, @"FSPathMakeRef failed");
    OSErr err = FSNewAlias(&fsHome, &fsFile, &aliasHandle);
    NSAssert(err == noErr, @"FSNewAlias failed");
    NSData* aliasData = [NSData dataWithBytes: *aliasHandle length: GetAliasSize(aliasHandle)];
    [[NSUserDefaults standardUserDefaults] setObject: aliasData forKey: key];
    }

    - (NSString*) loadPathFromKey: (NSString*) key
    {
    NSData* aliasData = [[NSUserDefaults standardUserDefaults] dataForKey: key];
    int aliasLen = [aliasData length];
    if (aliasLen > 0)
    {
      FSRef fsFile, fsHome;
      AliasHandle aliasHandle;
      OSErr err = PtrToHand([aliasData bytes], (Handle*)&aliasHandle, aliasLen);
      NSAssert(err == noErr, @"PtrToHand failed");
      NSString* homePath = [@"~" stringByExpandingTildeInPath];
      OSStatus status = FSPathMakeRef((unsigned char*)[homePath cStringUsingEncoding: NSUTF8StringEncoding], &fsHome, NULL);
      NSAssert(status == 0, @"FSPathMakeRef fsHome failed");
      Boolean changed;
      err = FSResolveAlias(&fsHome, aliasHandle, &fsFile, &changed);
      if (err == noErr)
      {
      char pathC[2*1024];
      status = FSRefMakePath(&fsFile, (UInt8*) &pathC, sizeof(pathC));
      NSAssert(status == 0, @"FSRefMakePath failed");
      return [NSString stringWithCString: pathC encoding: NSUTF8StringEncoding];
      }
    }
    else
    {
      NSLog(@"CardCollectionUserDefault was zero length");
      [NSAlert alertWithMessageText: nil
          defaultButton: nil
                         alternateButton: nil
                             otherButton: nil
      informativeTextWithFormat: @"CardCollectionUserDefault was zero length"];
    }
    return nil;
    }
  • I'm storing the bookmark data in an array displayed in a table:
    NSData *bookmarkData = [inAbsoluteURL bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
            includingResourceValuesForKeys:nil
            relativeToURL:nil
            error:&error];

    When the user double clicks on the row in the table I want to open the file.  I use this:
    NSError *error;
    BOOL isStale;
    NSURL *url = [NSURL URLByResolvingBookmarkData:bookmarkData options:NSURLBookmarkResolutionWithoutUI relativeToURL:nil bookmarkDataIsStale:&isStale error:&error];

    When the file's name or directory changes on my hard drive the resolved url == nil.  I'd like it to resolve to the actual file even if my app is closed and opened again (I'm saving the bookmarkData to repopulate the table the next time the user opens my app).  I thought that's what bookmarks did in 10.6 - I could be wrong.  An ugly workaround would be when the user double-clicks for me to create an actual alias file in a temp folder from the bookmark data and store that in my array, recreate it in a temp folder and launch that.  I'm sure that's wrong - there has got to be a better way.

    On Apr 3, 2010, at 6:55 PM, Ken Thomases wrote:

    > On Apr 3, 2010, at 5:20 PM, Brad Stone wrote:
    >
    >> I want to store a reference to a file in an ivar that will allow the user to change the file's name and/or the directory (i.e. the path) and still allow me to access it.  I don't want to create a file (like an ailas).  I need to store the file reference in a variable so I can open the file no matter where the user moves it or renames it.
    >
    > FSRefs have the property you desire.  As of Snow Leopard, though, the new recommended technique is to use a file reference NSURL.  Check the NSURL documentation and also:
    >
    > http://developer.apple.com/mac/library/documentation/cocoa/conceptual/LowLe
    velFileMgmt/Articles/FileManagementNSURL.html

    >
    >
    > Note that an alias _record_ is different from an alias _file_.  An alias record is data in memory and is suitable for this purpose, but perhaps overkill.
    >
    > As of Snow Leopard, alias records are deprecated in favor of bookmark data, but, again, it's probably overkill.  (Both alias records and bookmark data are more suitable if the reference is to be persisted for use by a later process.  Also, both can apply more robust searching heuristics to find an appropriate file even if it isn't the original.  For example, if the original is deleted and replaced with a new file of the same name.)
    >
    > Cheers,
    > Ken
    >
  • On Apr 18, 2010, at 10:43 AM, Brad Stone wrote:

    > I'm storing the bookmark data in an array displayed in a table:
    > NSData *bookmarkData = [inAbsoluteURL bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
    > includingResourceValuesForKeys:nil
    > relativeToURL:nil
    > error:&error];

    I am doing the same thing and it is still able to resolve the bookmarks when the file moves or its name changes. The only real difference I can see between our two approaches is that I am passing 0 for both the creation options and the resolution options.

    What are the properties of the error object are you getting when the bookmark resolution fails?

    -Noah
  • The error comes back "file does not exist" and the NSLog statement shows "url = (null)" after I change the name of the file in the Finder.  If I change the file name back to what it was when the bookmark was saved the file opens fine.  I changed my creation option to 0.  No difference.

    NSData *bookmarkData = [note valueForKey:@"bookmarkData"];
      NSError *error = nil;
      BOOL isStale;
      NSURL *url = [NSURL URLByResolvingBookmarkData:bookmarkData options:0 relativeToURL:nil bookmarkDataIsStale:&isStale error:&error];
      NSLog(@"url = %@", [url description]);

      if (error != nil) {
      [NSApp presentError:error];
      }

    On Apr 18, 2010, at 11:45 AM, Noah Desch wrote:

    >
    > On Apr 18, 2010, at 10:43 AM, Brad Stone wrote:
    >
    >> I'm storing the bookmark data in an array displayed in a table:
    >> NSData *bookmarkData = [inAbsoluteURL bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
    >> includingResourceValuesForKeys:nil
    >> relativeToURL:nil
    >> error:&error];
    >
    >
    > I am doing the same thing and it is still able to resolve the bookmarks when the file moves or its name changes. The only real difference I can see between our two approaches is that I am passing 0 for both the creation options and the resolution options.
    >
    > What are the properties of the error object are you getting when the bookmark resolution fails?
    >
    > -Noah
  • Are you sure the data is being stored into your "note" dictionary correctly? Here is my bookmark resolution code, it looks almost exactly like yours. I'm running on 10.6.3 and building for 10.6 with GC off.

    - (NSURL *)resolveBookmarkData:(NSData *)bookmark withOptions:(NSURLBookmarkResolutionOptions)options needsUpdate:(BOOL *)stale
    {
    NSURL *url;
    NSError *error;
    NSMutableDictionary *userInfo;

    error = Nil;
    *stale = NO;
    url = [NSURL URLByResolvingBookmarkData:bookmark options:options relativeToURL:Nil bookmarkDataIsStale:stale error:&error];
    if ( url ) {
      return url;
    }

    if ( error && [[error domain] isEqualTo:NSCocoaErrorDomain] && [error code] == NSFileNoSuchFileError ) {
      // error presentation and resolution code follows...

    -Noah

    On Apr 18, 2010, at 10:08 PM, Brad Stone wrote:

    > The error comes back "file does not exist" and the NSLog statement shows "url = (null)" after I change the name of the file in the Finder.  If I change the file name back to what it was when the bookmark was saved the file opens fine.  I changed my creation option to 0.  No difference.
    >
    > NSData *bookmarkData = [note valueForKey:@"bookmarkData"];
    > NSError *error = nil;
    > BOOL isStale;
    > NSURL *url = [NSURL URLByResolvingBookmarkData:bookmarkData options:0 relativeToURL:nil bookmarkDataIsStale:&isStale error:&error];
    > NSLog(@"url = %@", [url description]);
    >
    > if (error != nil) {
    > [NSApp presentError:error];
    > }
    >
    >
    > On Apr 18, 2010, at 11:45 AM, Noah Desch wrote:
    >
    >>
    >> On Apr 18, 2010, at 10:43 AM, Brad Stone wrote:
    >>
    >>> I'm storing the bookmark data in an array displayed in a table:
    >>> NSData *bookmarkData = [inAbsoluteURL bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
    >>> includingResourceValuesForKeys:nil
    >>> relativeToURL:nil
    >>> error:&error];
    >>
  • On Apr 18, 2010, at 9:43 AM, Brad Stone wrote:

    > I'm storing the bookmark data in an array displayed in a table:
    > NSData *bookmarkData = [inAbsoluteURL bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
    > includingResourceValuesForKeys:nil
    > relativeToURL:nil
    > error:&error];
    >
    >
    >
    >
    > When the user double clicks on the row in the table I want to open the file.  I use this:
    > NSError *error;
    > BOOL isStale;
    > NSURL *url = [NSURL URLByResolvingBookmarkData:bookmarkData options:NSURLBookmarkResolutionWithoutUI relativeToURL:nil bookmarkDataIsStale:&isStale error:&error];
    >
    > When the file's name or directory changes on my hard drive the resolved url == nil.  I'd like it to resolve to the actual file even if my app is closed and opened again (I'm saving the bookmarkData to repopulate the table the next time the user opens my app).  I thought that's what bookmarks did in 10.6 - I could be wrong.  An ugly workaround would be when the user double-clicks for me to create an actual alias file in a temp folder from the bookmark data and store that in my array, recreate it in a temp folder and launch that.  I'm sure that's wrong - there has got to be a better way.

    Hmm... have you tried converting the URL to a file reference URL first via its -fileReferenceURL method, and then generating a bookmark from that?

    Charles
  • SOLVED

    This works just as it should.  For reasons that I thought were valid at the time (I no longer think so) I had this code in writeSafelyToURL: right after the writeTofile: command.  What was strange was the url was valid because I was storing the bookmark after the file was successfully written to the hard drive but I guess there wasn't enough information in the file yet to make a valid reference (bookmark).  I moved it farther down the line with the exact same code and everything worked fine.

    Thank you for all your help.

    On Apr 18, 2010, at 10:43 PM, Noah Desch wrote:

    >
    > Are you sure the data is being stored into your "note" dictionary correctly? Here is my bookmark resolution code, it looks almost exactly like yours. I'm running on 10.6.3 and building for 10.6 with GC off.
    >
    >
    > - (NSURL *)resolveBookmarkData:(NSData *)bookmark withOptions:(NSURLBookmarkResolutionOptions)options needsUpdate:(BOOL *)stale
    > {
    > NSURL *url;
    > NSError *error;
    > NSMutableDictionary *userInfo;
    >
    > error = Nil;
    > *stale = NO;
    > url = [NSURL URLByResolvingBookmarkData:bookmark options:options relativeToURL:Nil bookmarkDataIsStale:stale error:&error];
    > if ( url ) {
    > return url;
    > }
    >
    > if ( error && [[error domain] isEqualTo:NSCocoaErrorDomain] && [error code] == NSFileNoSuchFileError ) {
    > // error presentation and resolution code follows...
    >
    >
    >
    >
    > -Noah
    >
    >
    >
    > On Apr 18, 2010, at 10:08 PM, Brad Stone wrote:
    >
    >> The error comes back "file does not exist" and the NSLog statement shows "url = (null)" after I change the name of the file in the Finder.  If I change the file name back to what it was when the bookmark was saved the file opens fine.  I changed my creation option to 0.  No difference.
    >>
    >> NSData *bookmarkData = [note valueForKey:@"bookmarkData"];
    >> NSError *error = nil;
    >> BOOL isStale;
    >> NSURL *url = [NSURL URLByResolvingBookmarkData:bookmarkData options:0 relativeToURL:nil bookmarkDataIsStale:&isStale error:&error];
    >> NSLog(@"url = %@", [url description]);
    >>
    >> if (error != nil) {
    >> [NSApp presentError:error];
    >> }
    >>
    >>
    >> On Apr 18, 2010, at 11:45 AM, Noah Desch wrote:
    >>
    >>>
    >>> On Apr 18, 2010, at 10:43 AM, Brad Stone wrote:
    >>>
    >>>> I'm storing the bookmark data in an array displayed in a table:
    >>>> NSData *bookmarkData = [inAbsoluteURL bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
    >>>> includingResourceValuesForKeys:nil
    >>>> relativeToURL:nil
    >>>> error:&error];
    >>>

previous month april 2010 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