Volume id shows as a tag

I keep dropping and rebuilding everything many times, trying to get it just the way I want and experimenting. So I know I am giving the software a good workout!

Anyway, here is another odd one that looks like a bug. Some strange string shows up in the UI.

Doing some digging, I came to discover that is the volume id of the /photos mount with all my originals.

Not had any problems in my many previous start-overs, is it because the mount is called /photos? Is that a reserved name or something?

Nope: it’s a timing issue.

The “37…nuuM” is the “volume sha”, and that tag is supposed to be updated with the mountpoint name as the “display name” (which is shown in the UI) periodically… Hopefully you see this get patched up automagically by the time your sync finishes?

But I just realized that’s dumb. I can just give it the proper display name at creation time, and then there’s no race with the tag maintenance jobs.

Thanks (as always) for reporting this! It’ll land with beta.10.

1 Like

Is there any way to hide this root volume tag? For my libraries I only have one volume, and it creates an extra click for navigation when going through the Folder view.

1 Like

@mrm - FYI, scan as completed and it still shows the volume id/sha on the UI rather than the mountpoint. The issue might be moot since you’re now gonna populate it immediately in beta.10, but this may be indicative of a larger problem, thought I’d let you know.

Ah, good point!

I think I can be more clever with handling this general case by automatically collapsing hierarchies that only have 1 child.

I’ll think about this more, thanks for the suggestion!

1 Like

@avdp thanks again for reporting this: what I described above is now in 1.0.0-beta.10.

@awojtas your auto-collapse suggestion is also in beta.10 :tada:

In this screenshot, we’re visiting the Folder tag for my root volume, but it sees that there’s only one child, so recursively collapse until there’s either multiple child tags or no child tags.

image

This also highlights a display issue that I hadn’t noticed before: the “root” directory is just /. I suspect this may be confusing or look like visual noise:

image

I understand what’s going on here, but I suspect most non-nerds won’t.

I wonder if there’s a better display string for the root (/) volume? Anyone got suggestions?

I’d just drop the root slash completely, I think it’s implied by the first grey slash.

Personally, at least on a docker/server install, I’d drop (rather than collapse) everything before the meaningful level. In other words, the root folder would be “Folder / test”. That’s because the internal mount point in the docker container doesn’t mean anything to someone perusing the web UI (see Open asset in external application - #15 by avdp) Perhaps the full path could be a mouse-over or something.

1 Like

I thought of doing that, but if you move your library to different machines, there will be different root volumes that we need to discriminate.

It could be “root on $hostname”, or “/ on $hostname”?

It’d look like this:

(I think I wouldn’t/couldn’t do this on docker, as the hostname is frequently a random string that changes every time you rebuild the container)

I wonder if the word “root” would pass the wife (or grandpa) test… I imagine they’d both look very confused if I told them to look for a file in the root folder. Sadly, I have no suggestion for alternate names since I am a nerd.

Anyway, when in doubt, make it a configuration? Show folder absolute path, or show relative path (with mouseover to the full / absolute path for the nerds)

Yeah, I agree with this entirely - it’s not about collapsing it, it’s just about not showing it. If you can’t explain it to your mum then you shouldn’t include it. My own mum uses PS, and I had to show her how to navigate down to the folders - I shouldn’t have to do that. She had to be shown, because it wasn’t obvious that she had to click the volume name to then see the library folder, and then could see the real folder hierarchy. If it doesn’t pass the mum test, it’s too hard.
Granted my mum is 70 years old but I still think she can navigate Google Photos just fine, so she should be able to navigate PS :slight_smile:

Does it matter if you move your library? This feels like an outlier use-case that affects everyone else.

1 Like

Agreed! That’s a solid litmus test. I’ll think about this a bit more… I guess I could have a flag on tags that say they don’t need to be shown in the UI when they’re part of a path? Hmmm.

Until I figure out how to gracefully elide the root partition, I did just add these two settings, which should help, especially if you’ve got nice labels:

  tagDisplayNameFSRoot: new StringSetting({
    category: SettingCategories.Tagging,
    description: `On POSIX systems, how should PhotoStructure reference the "root" directory (/)? If "/" is confusing, "root" might be an alternative...`,
    defaultValue: "/"
  }),

  tagDisplayNameFSLabels: new BooleanSetting({
    category: SettingCategories.Tagging,
    description: `Should PhotoStructure use volume labels, if available, as display names for filesystem tags? As an example, instead of showing "/ Folder / D:\", you'd see "/ Folder / Photo backup #3" (or whatever the label D: has).`,
    defaultValue: true
  }),

Aside - I was a product owner in a previous life, and it’s a frequent challenge to step back and make sure the UX is on point. A previous product owner I knew would use the mum test and I think it’s pretty legit.