It could, but the best way to see what’s going on is to check out your library db and debug logs.
You can actually tell if you open up your PhotoStructure library database (using something like SQLiteStudio or SQLite Browser, and check out the uri
column in the AssetFile
table.
There are 4 flavors of URIs:
-
Files in your library: those look something like
pslib:/2022/2022-12-31/image.jpg
-
Files on local or remote volumes that we have a volume UUID:
psfile://2NMQsMVCK/home/example/image.jpg
-
Files on remote volumes that we can’t read a
.uuid
for:psnet:/servername/sharename/path/image.jpg
-
Files on local volumes that we can’t fetch or read a
.uuid
for:file:///home/alice/Pictures/image.jpg
. Note that on Windows, the backslashes will be forward-slashed, and the drive letter will be in there:file:/C:/My%20Pictures/image.jpg
URIs using pslib:
and psfile:
should be reliable across platforms. The psnet:
scheme requires the server hostname to be stable (which isn’t guaranteed, you could use the IP address, a hostname defined in /etc/hosts, or a .local
zeroconf name). The file:
scheme relies on the full pathname (which obviously won’t be portable across platforms unless the paths match exactly).
Note that unicode pathnames are normalized to NFC before uriencoding. NFC is used by Windows and Linux. MacOS uses NFD, because macOS thinks different, so PhotoStructure has to do URI lookups with both NFC and NFD to ensure pathnames round-trip.