• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: URLByResolvingBookmarkData not case sensitive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: URLByResolvingBookmarkData not case sensitive


  • Subject: Re: URLByResolvingBookmarkData not case sensitive
  • From: Ken Thomases <email@hidden>
  • Date: Wed, 07 Jan 2015 09:25:13 -0600

On Jan 6, 2015, at 11:37 PM, Trygve Inda <email@hidden> wrote:

>> On Jan 6, 2015, at 8:43 PM, Trygve Inda <email@hidden> wrote:
>>>
>>> Ultimately what I need to able to do is compare a bookmark to a path.
>>
>> Why? Or rather, what is the reason underlying that one?
>
> I am keeping a database of files that the user adds to a database.
> Internally I keep the bookmark to each file but also cache the file's path
> as it is faster to work with.
>
> When adding new files, I need to make sure the file is not already in the
> database so I compare the paths. This works well except when the case
> changes. In that situation a file might be added that is already in the
> database and since the bookmark is resolving to an old path (same path but
> different case), the compare method fails unless it is made case
> insensitive... But not all file systems are case insensitive.
>
> So it needs to be fast... When I add a file, I might already have a few
> thousand files in the database.

I think you should only store bookmark data in the database.  When you load the database at program start, it may make sense to resolve the bookmark data to a URL, although the user could move or rename a file while your app is running so you would need a way to fall back to the bookmark data in any case.

As Stephen Butler suggested, all subsequent comparisons to see if two URLs refer to the same file should be done using the file resource identifier obtained using NSURLFileResourceIdentifierKey.  That's what it's for; it's meant to be the _right_ way to compare references to files, bypassing issues with symlinks, hard links, case differences vs. file system case (in)sensitivity, etc.  The URL object will cache the value making it fast to obtain.  If you don't think it's fast enough, you can cache that yourself, too.

You should be able to obtain the file resource identifier from just the bookmark data without resolving, if that is helpful.  See +[NSURL resourceValuesForKeys:fromBookmarkData:].

Regards,
Ken


_______________________________________________

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

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >Re: URLByResolvingBookmarkData not case sensitive (From: Trygve Inda <email@hidden>)

  • Prev by Date: Re: URLByResolvingBookmarkData not case sensitive
  • Next by Date: Re: NSScrollView autolayout (10.10)
  • Previous by thread: Re: URLByResolvingBookmarkData not case sensitive
  • Next by thread: Re: URLByResolvingBookmarkData not case sensitive
  • Index(es):
    • Date
    • Thread