Yes! it’s actually the first 52 bits (encoded in radix58, so 9 characters) of a SHA512 of the volume UUID.
Taking a step back, PhotoStructure’s “assets” (the things you see in the UI) are backed by 1 or more
AssetFiles, and is how it manages de-duplication. If you are automatically copying asset files into your library, one (or more) of the AssetFile URIs will be prefixed by
pslib:/ rather than
So, if you mount the
psfile://2cpTTHxQy volume on your NAS (presumably via exporting all of Z: via SMB to your NAS, or by physically moving Z: as an external drive to your NAS), the paths will “just work”: they’ll render the same URI, so they’ll be considered the “same” asset file.
If you instead share a subdirectory within `Z: to your NAS, all bets are off: PhotoStructure will consider it a new volume, and those files, as viewed by your NAS, will have different URIs, so new AssetFiles will be added to your library (to your existing Assets).
(Things get complicated with unicode filenames and “interesting” OSes like macOS, which does non-standard unicode normalization, but PhotoStructure still handles it in either case).
Making code work once is hard enough. Cross-platform development drives a man to (in moderation, of course).