• 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: On NSIncrementalStore UUID Uniqueness
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On NSIncrementalStore UUID Uniqueness


  • Subject: Re: On NSIncrementalStore UUID Uniqueness
  • From: Daryle Walker <email@hidden>
  • Date: Thu, 19 Jan 2017 16:18:42 -0500

> On Jan 16, 2017, at 12:08 PM, Charles Srstka <email@hidden> wrote:
>
>> On Jan 14, 2017, at 4:41 AM, Daryle Walker <email@hidden <mailto:email@hidden>> wrote:
>>
>> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive file moves. There are file references in macOS, which would be more stable, but I read that there’s a bug in the URL class where it would degrade file-reference URLs to standard-file URLs, so that’ll be problematic. Another solution would to create bookmark data from a file URL and take a hash of that. But are multiple bookmark data blocks of the same file URL consistent enough for this idea to work?
>
> The thing with file reference URLs degrading to file path URLs is in the Swift is actually not a bug, it’s deliberate (https://bugs.swift.org/browse/SR-2728 <https://bugs.swift.org/browse/SR-2728>). The Swift team decided that file reference URLs are not appropriate for the Swift URL value type. However, if you’re using Objective-C, file reference URLs will still work fine, and you can always make an Objective-C wrapper that stores a file reference URL and use that from Swift.

I looked at some code that gives a workaround for the file-reference URL problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit values, then sprinkles those onto a URL string template. Since UUIDs are 128-bit values, I could just copy a reference ID directly into a UUID. However it means existing files would have a different style, possibly overlapping, than new files (which would take a random UUID). Maybe it’ll be better to always use a random UUID, the implementers do in practice.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

_______________________________________________

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


  • Follow-Ups:
    • Re: On NSIncrementalStore UUID Uniqueness
      • From: Jean-Daniel <email@hidden>
    • Re: On NSIncrementalStore UUID Uniqueness
      • From: Charles Srstka <email@hidden>
References: 
 >On NSIncrementalStore UUID Uniqueness (From: Daryle Walker <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Jean-Daniel <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Jens Alfke <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Keary Suska <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Daryle Walker <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Charles Srstka <email@hidden>)

  • Prev by Date: Re: On NSIncrementalStore UUID Uniqueness
  • Next by Date: Re: On NSIncrementalStore UUID Uniqueness
  • Previous by thread: Re: curious: if not file references, what?
  • Next by thread: Re: On NSIncrementalStore UUID Uniqueness
  • Index(es):
    • Date
    • Thread