File rejected / deleted - missed by directory sync

Maybe it’s a bug or maybe just something about my environment causing the weird behavior… but, either way, I find the message reported (“missed by directory sync”) very unclear. If nothing else, that text could be improved (or at least explained on this forum or the website; so far I’ve found no mention of it anywhere).

I mean, what does “missed” even mean in this context!?
What actually happens, what could lead to it, how to avoid that happening again?

Perhaps PhotoStructure should “aim” better if it keeps “missing”. :wink:

Expected Behavior

PS ‘sync’ - as long as it’s not interrupted - should load all “valid” files from ‘scanPaths’ into its database.
And running it again with the same source volumes should result in an unchanged library state.

Current Behavior

Seems like every time ‘sync’ runs (either automatically after a day or forced full resync) I end up with a slightly different database state. The “assets” in the library (auto-organized) remain the same, but the “files” (and the ‘fs’ tags representing the original folder structure) come and go.

sync-report’ includes lines like:

*,*,*,deleted,updateAssetFile_(),*,rejected: missed by directory sync,,

The log (‘info’ level):

...03:00:53.222Z sync error_ models.AssetFile(<id>) .getNativePath() called before .setFile_()⁹
...03:00:53.372Z sync warn_ updateAssetFile(<id>) file was deleted or rejected. Deleting. { id: <id>,
  assetFileId: <id>,
  path: '/mnt/...',
  uri: 'psfile://...',
  rejected: 'missed by directory sync',
  deleted: false }
...03:00:53.373Z sync info_ sync.DirectorySync(/mnt/...) onTaskResolve() non-syncFile task { task:
   { '$ctor': 'models.Task',
     id: 1,
     fn: 'updateAssetFile',
     argsJSON: '{"assetFileId":<id>,"whyReject":"missed by directory sync"}',
     priority: 13,
     retries: 0 },
  result:
   { id: <id>,
     assetFileId: <id>,
     path: '/mnt/...',
     uri: 'psfile://...',
     rejected: 'missed by directory sync',
     deleted: false },
  elapsedMs: 137 }

(Picked the few records that seem related to one file. They are usually interleaved with similar “warnings” for many /but not all/ other files from that same folder… and a few similar “errors” on top - but only for a subset of those removed files.)

The ‘photostructure list’ command - no longer includes the files now “rejected” (my ‘/ps/originals/…’ copy is there, but the source ‘/mnt/…’ is not).

Running a full ‘sync’ again - I usually get those missing files “back” but then some random files in other folders “disappear”. Tried it a couple times over a few days - it wasn’t entirely “random” - but like bouncing between a few folders (out of thousands). Overall, this library has ~100k assets, ~240k files (with ~140k coming from that single mounted volume, the rest being auto-organized and de-duped PS library’s “originals”).

Workaround?

‘photostructure sync <path>’ - for the specific folder that had any “missed” files - hoping to get them all eventually… and then make sure it never “scans” that volume again.

In the end, this worked for me in this particular instance, because I wanted PS to literally just “re-organize” a bunch of photos into a nice year/date-based library… while preserving the original folder hierarchy only as ‘fs’ tags on those assets (for searching, browsing in the app, etc.). Once I have it all “loaded”, I intend to delete the source and never “mount” that volume again.

But I still don’t understand WHY it was happening… and am worried if will happen again when (re)syncing other volumes.

Environment

PhotoStructure for Docker - 2024.3.3-beta
Running on Debian 12 inside a ProxmoxVE LXC.
The ‘/ps/library’ and ‘/ps/originals’ are mounted local LXC disks.
And that ‘/mnt/…’ source volume is a CIFS/SMB share from a Win11 VM on that same ProxmoxVE host (so, technically a “remote” file system, although it happens to be on the same machine :)).

It’s not impossible that it’s my unusual virtualized setup what’s causing instabilities in filesystem lookups (file exists and then it doesn’t?)… but it sure would be surprising. Other than PS syncing, I’ve never noticed any weird behavior in accessing those shares. Perhaps if I knew exactly what it is that trips PS up, then I could try to reproduce it outside of the sync process.

Thanks for taking the time to compile this together! I’ll look for the code path that emits that message, explain it more here, and improve the verbiage.

1 Like