I’ve been using a self-written file watcher together with the nodejs version of photostructure to call sync-file and sync changed/added/removed files in photostructure, this worked great.
I’ve since moved photostructure to docker and I’m trying to get photostructure to sync files with the file-watcher again.
However the process of doing this with docker is to first establish a ssh session to the docker server, then using docker exec to run a command within the container and finally ask photostructure to sync the file. The quotation escaping is fun
Is there a better way? The following seems to work when run interactivly in powershell however I’ve not got it to fly running unattended as a service (don’t know why yet…)
Would it be possible to add a first HTTP/REST based API to just tell photostructure to sync a filepath? I don’t see any major risks with this as long as this call pass the file criterias as a normal sync would. It could also be validated that the requested path to be scanned is within the bounderies of search-paths already defined in the settings.
That’s certainly doable, but there would have to be some caveats.
If the directory isn’t currently in your scanPaths system setting:
a. it will only import that directory once
b. if you shut down sync and restart, it won’t resume the import.
If the directory is in your scanPaths system setting:
a. it will stop the current sync, if one is running, in that directory, and then
b. it will flush all prior sync state for that directory, and then
c. it will restart syncing that directory from scratch.
In either case, it’s unclear what would be “intuitive” behavior for sync to do if it was currently syncing a directory. Should it pause that work? Should it work on the existing work and the new dir at the same time? What happens if you gave it 10 directories in rapid succession? Slowly sync all dirs simultaneously?
True, that is some things needing consideration. I’ve given it some though and personally I think that a manually initiated sync should be expedited and processed before the regular scheduled sync. So the regular sync should be paused until the queue of manually initiated syncs are completed and then resumed.
I don’t know how processing of the files work but in my mind it’s some kind of queue (?). If a scheduled sync is started and then manual sync of directory that is not yet processed by the scheduled sync, maybe it can be ignored by the scheduled sync since it has already been synced by a manual sync during the “session” of the scheduled sync?
And last regarding requested manual syncs of paths not included in scanPaths. Imo maybe this should not be allowed. As you say it might raise confusion as to why pictures are imported once and never scanned again. A simple message saying “The requested path is not defined in your configured scanPaths setting”. So a prereq is that all paths that you ask photostructure to sync is within the bounderies of the configured scanPaths settings.
This is my take on these things
I might note as well that all this would be obsolete to me if photostructure could watch for file changes. Our family use photostructure to consolidate the steady stream of daily photos and a means to share them. So if I want to share a picture, rather than sending it and creating multiple copies I would rather just say, I’ve synced my pictures, they are in PS. Currently 24 hours sync is to long and running it hourly is a lot of overhead. Therefore the filewatcher work-around at the moment.
