Adding \\server\someshare\somefolder does nothing

Adding a local D:\somefolder dir works fine, albeit not all subfolders are shown directly (needs to go to folder view and then click on a breadcrumb to get at the other files)… but that is another topic.

Adding a path to a server doesn’t sync the files there.

I added a .uuid file (generated from powershell) to \server\someshare\somefolder dir and it didn’t work so I moved this .uuid file to \server\someshare instead and still not getting any photos.

Is SMB supported?

Windows version Beta 14

Howdy @Stecy , welcome to PhotoStructure!

TL;DR: yes, Windows UNC paths (\\server\share) should work, both as the path to the library, and paths to be scanned for assets, but due to Windows internals, I’d recommend mapping the UNC path to a network drive and giving PhotoStructure a drive letter instead.

Replies inline:

Oof, sorry about that. I may have found what you’re describing last night when I was testing on my windows box and believe I’ve fixed that issue in v1.0.0-beta.15.

If you try out beta.15 and it’s still happening, I may be misunderstanding what you’re describing: it’d be great to get an update either way.

That’s a bug: I’ll look into this.

Yes, absolutely. SMB shares via network-mapped drives should be solid.

I’ve found UNC paths to be persnickety: stat and readdir will fail or timeout randomly, and PhotoStructure does have timeouts and retries built-in, but I’ve found that simply mapping the network drive fixed those issues (at least with my test rigs and my test NASes: your network setup may behave differently).

Another advantage to mapped network drives is if you use “automatic scanning” for assets, PhotoStructure can’t “discover” UNC paths, so it can’t automatically sync them like it can with drive letters.

Hi,

I’ll use mapped drives then, no problem. So the UUID should be at the root of this drive? What happens if I later on move the library and server on a synology NAS? Where should I put the uuid file?

Also, beta 15 seems not available :wink:

Thank you very much,

:+1:

Yes, PhotoStructure looks for volume .uuid files in the root directory of the volume mountpoint, so, \\nas\homes\.uuid or C:\.uuid.

However, you shouldn’t normally need to worry about UUIDs: PhotoStructure should set them as needed (and will try to use the actual physical volume UUID, if available).

The only time (that I can think of) where you’d need to set up volume UUIDs manually is if you don’t want to give PhotoStructure write-access to the root directory of a given volume.

In any case, take care to not re-use .uuid values across different volumes!

If you want to move your library:

  1. Shut down PhotoStructure
  2. Copy or move the entire library to your NAS (if you can use a tool that retains file timestamps, like cp -rp or rsync -a, that’s better)
  3. Restart PhotoStructure. If you moved your library, PhotoStructure will guide you to changing to your new library location. If you copied your library, go into the Settings page and change the library directory there.

Note that assets found in your library are internally referenced from the root of the library (or PS_ORIGINALS_DIR) via URIs, so volume UUIDs don’t come into play (and is one of the reasons why libraries are cross-machine and cross-platform compatible).

Yeah, I didn’t ship it last night. My windows VM decided to corrupt itself after GitHub Actions’ outage yesterday: I just got it restored now and am triaging the failing test.

(in case you’re interested: there are now 1438 fe tests, 4375 core tests, and 865 library tests that all run on macOS, Linux, and Windows via GitHub Actions CI).

1 Like

Looking at the data from the database (table AssetFile) I see columns uri and mountpoint.
I have setup, for testing, a folder at D:\PhotosTest\ and those columns shows:

uri mountpoint
psfile://2cpTTHxQy/PhotosTest/Medias/SomeAlbum/P1010786.JPG D:|

Is the 2cpTTHxQy the uid?


About moving the library to the NAS, which references a drive letter while the server is on Windows (Z:). Will the migration process detect that Z: does not exist on my NAS :wink: and offer to rebase the folder on to something like /volume1/public/medias ?


As a programmer myself (C#) I’m quite interested in those technical details :wink: and I’m glad you’re having tests :clap: :clap:

Have a nice day/evening/night :slight_smile:

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 psfile:/.

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 :tropical_drink: (in moderation, of course).