Talk:Universally unique identifier

We need more material in this article

As a Linux user, I understand the importance and awesomeness of UUIDs. However, I'd like to know more. For instance, when did the idea of UUID come into creation? When was it created as a set standard? What I'm trying to say is that this article needs more dates, years, names of people related to those things. --Cyberman (talk) 02:31, 14 June 2008 (UTC)

ETC

What is Leach-Salz? --Abdull 15:16, 4 April 2007 (UTC)

The UUID variant described in RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", by Paul Leach, Michael Mealling, and Rich Salz. Guy Harris 17:44, 4 April 2007 (UTC)

Perfect answer, thank you very much! I first thought it has something to do with salt... --Abdull 18:55, 4 May 2007 (UTC)

The article mentions version 1, 3, 4 and 5. What is version 2 then? If it was not released, (version skip) I think this should be mentioned. Now it seems like something has been forgotten... --Patrickdepinguin 13:40, 22 June 2007 (UTC)

It was used. See the item I added, and the document to which it refers. Guy Harris 17:42, 22 June 2007 (UTC)

private-use UUIDs?

The article doesn't make clear if there is a "private-use" address space for UUIDs, i.e., some rules to create UUIDs not intended to be exported from a closed system, like we have IPv4 and IPv6 private networks, Unicode's Private Use Area, the .local domain name, local-use EAN-13 barcodes and so on... The most logical idea is to use a specific reserved version number, but the RFC 4122 doesn't seem to mention anything other than the 5 versions (clock, dce, md5, random and sha1). --Juliano (T) 01:39, 20 August 2007 (UTC)

AFAIK there are not such "private use" UUIDs. The inventors of these UUIDs claim that the collision risk is small enough that in practise there are no collisions, so there is no need for "private use" UUIDs. --81.27.124.161 (talk) 21:22, 9 April 2008 (UTC) (RokerHRO)

Collisions

"This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs." this leads to misunderstanding. While the number space is that big, chance for a collision are much higher, indeed! I.e. see http://en.wikipedia.org/wiki/Birthday_paradox —Preceding unsigned comment added by 84.129.161.7 (talk) 03:16, August 30, 2007 (UTC)

Duplicate UUID's on hosts

IS it possible to have same valid UUID on multiple hosts in a network? —Preceding unsigned comment added by 128.222.37.20 (talk) 05:15, 13 September 2007 (UTC)

It is, but very unlikely as explained in the article if the UUIDs are chosen randomly. --81.27.124.161 (talk) 21:24, 9 April 2008 (UTC) (RokerHRO)

"Well Known" UUID's

Perhaps a section should be added to list some well known UUIDs. The article already uses the MS IUnknown UUID as an example of such a UUID - however a more exhaustive list of "known" aka documented UUIDs that are for specific uses should be added.Myrdred (talk) 16:43, 9 February 2008 (UTC)

Am I the only one horrified by this idea?

What a terrible idea! So basically because we can't be bothered to create a central listing of things, we're just generating an enormous gillion-character string and "hoping" that since it's so big it's not going to collide?! This is used in ext3?! Wow I feel great knowing that the only reason my filesystem isn't catastrophically corrupted is because I'm lucky. This type of thing might have limited applications where it's impossible to safely merge IDs that could potentially collide (can't imagine why it would be impossible but maybe for some crazy deep space probe where energy can't be spared for merging processing and high bandwidth is critical), but for labelling articles on E's website?! This is terrible programming! :D\=< (talk) 02:11, 2 March 2008 (UTC)

It is not enormous, it is not gillion-character, and it is not a string. It is a 128-bit number. The purpose of UUID is to be used when you simply don't have any means of using a central registry. Two autonomous systems, with no previous established communication between them, or access to the Internet may create lots of objects identified by UUIDs, than they can merge together into one, and their objects will still be unique.

Or do you really want to force everyone making a filesystem on a newly-installed system to have an Internet connection, in order for mke2fs to connect to a central registry to create the UUID of your partition? And even in the remote possibility of two objects in the universe having the same UUID, it is easier to believe in the existence of the Invisible Pink Unicorn than they happening to coexist on the same context.

Your filesystem won't be catastrophically corrupted just because it has the same UUID of a news article on some website. It won't be corrupted even it there was another object on the same computer with the same UUID. You have to be extremely unlucky to get two partitions with the same UUID on the same computer, and even so, your biggest problem will be referencing one of them by UUID when mounting, something very simple to fix.

The principle is the same of hashing. For mission-critical systems, you either won't depend on UUIDs or will properly handle UUIDs so that they don't collide or collisions will be treated accordingly.

--Juliano (T) 17:00, 9 March 2008 (UTC)

And how is a filesystem not mission-critical? And give one example where you can't have a central registry. I don't understand why partitions have UUIDs- they're already registered in the drive's partition table, and each hard drive's partitions are numbered and made available by the BIOS. No need for an internet connection of course. Obviously there are cases where data needs to be merged and still have a unique identifier but if you actually give some processing to sorting through the data and preventing collisions, reissuing identifiers, and generally doing what a merge should be doing, then you have no problems. It's a lot slower than just issuing huge UUIDs to everything and crossing your fingers, which does work, but come on! How ugly! This is not the right thing. :D\=< (talk) 15:19, 10 March 2008 (UTC)

Yes, sure a filesystem is mission-critical... but the data contained into it, not its identification along all the partitions of the system. Once you build a mission-critical system, the UUIDs of the partitions are set on stone and won't change anymore during its mission-critical activity. You use UUIDs only to identify each partition among the others, only. Once mounted, the kernel uses its (major, minor) tuple to access it. And you are thinking too strictly... forget the BIOS and the drive's partition table. A computer is not restricted to having a single drive.

Think you have 2 hard drives on your computer, each one with a few partitions, and each partition identified by its UUID. If you consider the possibility of changing their internal connections, referring them by their /dev/sdXY path becomes inherently broken. Using UUIDs, you buy a new SATA PCI card and move one of the disks to it, the system will boot with all mount points in place, like if nothing changed. Or you buy an USB enclosure, put the other disk into it and plug it into the USB port, the system will still boot and mount all the partitions properly on their mount points, since they still have the same UUIDs they had when created. You bring a hard drive from a friend, and plug it anywhere on your system reassured that it would be easier to win three consecutive times the Lottery's full-prize than having his partitions colliding with yours (unless he knew beforehand one of your systems partitions UUID and set on his drive, but this is another problem).

With dynamic and redundant disk systems, like LVM and RAID, where disks and partitions may be freely moved and newly ones added, UUIDs are even more important. You ask for one example where you can't have a central registry... disk partitioning is pretty much an excellent example. Creating and formatting RAID partitions on hardware RAID implementations are done by the BIOS, before the operating system is loaded. How you can think of using a central registry in this case?

I work with distributed computing, process migration and some grid computing. We use UUIDs extensively to identify nodes, tasks and all sort of objects being processed and passed around. Objects must be unique on a system that is not fully connected. Sections of the system get disconnected from the rest and get reconnected a few hours later. The idea of a central registry for UUIDs is simply crazy and stupid. Half the objects created don't even live for more than a few seconds. A central registry not only would slow everything down, it would break its mobility and create a single point of failure, for no added value. Such a distributed system is inherently designed with fault-tolerance in mind, since you may spawn a task to a node, the node crashes and you won't ever receive its answer back. UUID collision is not even considered, it is a non-issue.

And talking about BIOS, your worst nightmare is already becoming true. The BIOS is obsolete and is currently being replaced with the Extensible Firmware Interface, which in turn replaces the old and obsolete Master Boot Record with the new GUID Partition Table, heavily based on UUIDs. Sorry.

--Juliano (T) 17:19, 10 March 2008 (UTC)

Froth, I thought about this problem too. I guess I would feel safer if all programs that use UUID's are written to handle UUID collisions safely, but I guess the probability of collision is known to be too small to bother with. I wonder if there are many life-and-death applications that blindly depend on uniqueness of UUIDs, e.g.avionics, railways, medical equipment. Perhaps only the most hardnosed engineer/mathematician-types would feel safe. Glueball (talk) 11:47, 21 April 2008 (UTC)

xxxxxxxx-xxxx-3xxx-xxxxxxxxxx

This pattern is supplied in the section on Version 3 UUIDs. Isn't there a group of four hex digits missing here? I hesitate to correct it myself in case I'm missing a key point about version 3. Jimgawn (talk) 18:36, 11 April 2008 (UTC)

Where UUID stored?

Please say where the UUID number is stored in flash memory cards.

I have a CF card that shows up as

/dev/disk/by-uuid/2004-1223 -> ../../sdb1

and an SD card that doesn't seem to have a UUID. Can one use e.g., the GNU/Linux dd command to see where the UUID is stored? Jidanni (talk) 01:24, 13 July 2008 (UTC)

It is not a property of the SD card, but of the partitions contained in it. It is part of the filesystem, depending on which filesystem you have in it. This number (2004-1223) is most likely to be a 32-bit FAT volume serial number, which is not an UUID as described in this article.

This number is chosen when you create the filesystem in (ie, format) the SD card. On Linux, you may force a given number by passing the -i xxxxxxxx parameter to mkdosfs.

The FAT article tells exactly where the serial number is stored inside the partition, but this is out of the scope of this article. UUIDs are not used by Windows to identify its partitions.

--Juliano (T) 17:35, 13 July 2008 (UTC)

Is there an error or am I a bad counter?

I think, that 8+4+4+4+12=32 not 36?