Devices do not have UUIDs. Partitions do. UUIDs are created when a filesystem is formatted. This is why they can be changed, and why they do change when you reformat.
In other words, a UUID is not a characteristic of piece of hardware, and there is no way to "find" information that does not exist.
There may be one or more partitions on the device that have UUIDs, so if you have seen one before associated with it, it's the UUID of a partition. If there is more than one partition, there may be a UUID for each one (there also may not, since none are required), but none of them are characteristics of the hardware (they're just mutable pieces of data stored on it). USB keys usually come with one big pre-formatted FAT32 or NTFS partition. If you reformat this, the UUID will change.
To find the UUID of a partition, you do need to find its identity as a block device. cat /proc/partitions should list everything the kernel is aware of, mounted or not. Presuming there aren't dozens of drives attached to your system, it should be simple enough to figure out which one is the USB. /proc/partitions actually lists the drive too, you can tell this apart from its partitions because the drive won't have a number at the end (sda vs. sda1), and file -s output will be different:
> file -s /dev/sda
/dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 134217728 sectors;
partition 2: ID=0x83, starthead 202, startsector 134219776, 58720256 sectors;
partition 3: ID=0x83, starthead 245, startsector 192940032, 46137344 sectors;
partition 4: ID=0x82, starthead 223, startsector 239077376, 10992304 sectors, code offset 0x63
> file -s /dev/sda1
/dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=cd8e11b5-07ac-7741-ae0c-36e63eacf8a1, volume name "_Fedora-17-x86_6/" (needs journal recovery) (extents) (large files) (huge files)
Sometimes the preformatted drives are just one big device, eg:
> file -s /dev/sdb
/dev/sdb: x86 boot sector, Microsoft Windows XP Bootloader NTLDR, code offset 0x3c,
OEM-ID "MSDOS5.0", sectors/cluster 64, root entries 512,
Media descriptor 0xf8, sectors/FAT 246, heads 255, sectors 4026368 (volumes > 32 MB) , reserved 0x1, serial number 0xe06de56f,
unlabeled, FAT (16 bit)
Notice this one is in fact "unlabelled" and appears to have no UUID (they are not mandatory).
tldr: It's ok, no possible data corruption.
Asked at the mailing list too, and they explained that the subvol UUID
is just used a sanity check for btrfs send and btrfs receive.
...
The UUIDs on subvols are only
really used internally to that filesystem, so the kernel doesn't have
a chance to get confused. The main thing that could be confused is
send/receive, but that's a matter of possibly losing some validation
(thus allowing you to do something that will fail) rather than causing
active damage, as in the duplicate-FS-UUID case.
...
from https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg49133.html (was http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917)
Now I can sleep better :p
Best Answer
You asked
And the answer to this is "yes, definitely".
If you prepare the environment like this:
You can modify the path to get a static UUID on each call, like this