New "easy mode" for Docker coming in v2.1

📢 Announcements
,
41

Just chiming in, I also find the hidden folder to be uneccessary and a mild annoyance. I would welcome this change.

I get the intend behind it, but I think a README in the root folder that says “Don’t manually mess with these files or else” would be sufficient CYA.

EDIT: frankly, the more I think about it, I think the hidden folder might generate another kind of support call. Someone might just delete the folder thinking it’s empty. I mean, your use case is for user not sophisticated enough to even look for hidden folders, right?

42

This really depends on the setup. For instance, if you export the host directory via SMB (as is common in Unraid) and then pull that directory up in Windows, then the dot prefix doesn’t render the folder as hidden… it just looks like any other directory.

That said, if we’re talking about ideal (for the docker version), my preference would be to have my host directory be ../appdata/photostructure/ and then have everything that’s currently in .photostructure in that folder.

But again, I’m pretty meh about it either way.

43

Thanks for sharing, you guys. I think you’re right, @adamf about adding complexity. I’ve reverted that change.

I suspect (most? many?) people won’t care where these directories go–they just want the thing to work.

If you do care, you can either set up the bind-mount to point where ever you want, or set PS_LOG_DIR, PS_CONFIG_DIR, PS_CACHE_DIR (and even PS_LIBRARY_DIR) to whatever sparks joy.

As far as making directories visible or moving the defaults: I want to maintain cross-OS and cross-machine library portability. If the library is moved to a Windows or macOS box which doesn’t use the same system cache or system logging directories, it’s no big deal–the library contents stay the same. Conversely, we don’t want the system configuration to be shared between editions, so it’s fine to adjust the docker-config heuristics–PhotoStructure for Node and PhotoStructure for Desktops won’t look at any docker-config directory, so we’re good there.

44

Soo… where does that leave everything? Back to current behavior, or is the folder not hidden at least?

45

I rolled back the changes after

  1. I realized everything was already configurable, and complications here would lead to confusion
  2. I don’t want to write a automatically-adopt-different-folders-upgrader.
  3. Any folder structure won’t make everyone happy. As everything is already customizable via settings, you already have the flexibility to put folders right where you want them.
46

I’m trying to minimize the number of settings required outside of defaults while also taking advantage of the new simple docker bind mount mode which, thankfully, has the potential to reduce my bind mounts from 4 down to 1.

I think I settled on 2 bind mounts though for the docker directory. Here’s where I am. Do you foresee any issues with this, and also any possible improvements?

(Commented lines for testing)

  photostructure:
    image: photostructure/server:alpha
    container_name: photostructure
    restart: unless-stopped
    networks:
      - $TRAEFIK_NETWORK
    security_opt:
      - no-new-privileges:true
    ports:
      - 1787:1787
    runtime: nvidia
    stop_grace_period: 2m
    volumes:
      - $MEDIADIR/photos:/photos
      - $DOCKERDIR/photostructure:/ps/library
      - $DOCKERDIR/photostructure:/ps/library/.photostructure
    environment:
      - TZ
      - PUID
      - PGID
      - UMASK=002
      - NVIDIA_VISIBLE_DEVICES=all
      - PS_LOG_LEVEL=warn
      #- PS_START_PAUSED=true
      - PS_ORIGINALS_DIR=/photos
      - PS_MAX_ASSET_FILE_SIZE_BYTES=0
      #- PS_TRANSCODE_VIDEOS=false
      - PS_ENABLE_EMPTY_TRASH=true
      - PS_ENABLE_REMOVE_ASSETS=true
      - PS_ASSET_PATHNAME_FORMAT=y/MM/y-MM-dd/BASE
      - PS_DISABLED_HELMET_MIDDLEWARE=all
      #- PS_FFMPEG_HWACCEL=auto
47

Interesting! Is the first bind mount really neccessary? I think I am going to try this…

48

I believe if I remove the first one, the .uuid file that is created in /ps/library won’t be retained upon container restart which could cause problems.

49

I think I’m missing something. Why would you map the same host directory to two different (and nested) container directories? With that setup, if you ever drop a file into your $DOCKERDIR/photostructure directory, it’s going to show up in the container twice, once in /ps/library/ and once in ps/library/.photostructure. Likewise, any files that the container creates in either of those directories is going to show up in the host directory all mixed up together. Seems like a lot of added confusion. What’s the upside?

50

I think it’s an attempt to not have that pesky .photostructure hidden folder in the library folder, but yeah, this is weird.

51

If that’s the case, then I think the best solution is to limit the need to ever go into the library directory. If you add a separate bind mount for /ps/logs and ps/config (and also ps/originals if you use auto-organization), then the only reason you would ever need to go into the .photostructure directory is to view/change the library settings.toml file. If you never have to go there, then the existence of the hidden .photostructure directory is inconsequential.

52

@tkohhh Not wanting the .photostructure level on disk is purely cosmetic. It’s not an issue of “need”.

53

Currently there are no files created (to my knowledge) ever at the sibling level to the .photostructure directory except for the volume .uuid file, so there won’t be any mixed up concern.

I also don’t really mind what the intra-container directory structure looks like since on the host everything is clean and the .photostructure subdirectory is empty.

I used to have separate log, config, etc. mounts but I’m trying to leverage the docker easy config to have fewer bind mounts, else I would just fall back to my 1.1 config variation - hence trying to get this to work instead. I also am using originalsDir so I wouldn’t need to set /ps/originals to my knowledge.

So the upside I guess is, my entire PS folder structure is simply $DOCKERDIR/photostructure and I can see my logs, models, etc. folders, the settings.toml all without having to drill down an extra layer into .photostructure.

54

So the only upside is that you don’t have to add a -a flag when you’re doing an ls in that directory? Just want to make sure I understand…

55

It’s really just a parity of organization. None of my other containers have their data at $DOCKERDIR/app/app/content, it’s all at $DOCKERDIR/app/content. Sometimes I’m creating extra folders in the docker directory to rsync copy or backup content, test, etc. - and I want to quickly ls a folder or du a folder to see if it’s empty, etc.

I don’t want to have to remember which folders contain hidden content - I just want to quickly fly through and ensure I’m not pruning things I shouldn’t be pruning, etc.

56

For me, it is less about the folder being hidden than it is about it existing at all. In my docker/unraid setup (“easy mode” with PS_LIBRARY in appdata, and not moving files) it serves no purpose. Super minor annoyance, but if I can bind mount my way into a cleaner structure, why not?

57

Correct. I only make dated subdirectories in $PS_LIBRARY (which depends on your assetPathnameFormat setting, of course!).

With this double-overlay mount strategy, all your original photos and videos show up twice (once in /ps/library/yyyy/..., and again in /ps/library/.photostructure/yyyy/..., but that should be OK, given that sync should skip over .photostructure and not see all the “dupes”.

58

I just came across this page on the docs which does not seem to have been updated for Docker Easy Mode: PhotoStructure | PhotoStructure for Docker

I think you should consider updating it so new users know about Easy Mode.

59

Done! Thanks for the reminder.