After PhotoStructure imports files into its library using the “automatic organization” feature, I’d like the ability to delete the originals once it’s known to be safe (eg. checksum is verified to match the original file).
I understand why PhotoStructure doesn’t move original files, but in my case I’m not dealing with old files, and instead want to have an “imports” directory that I copy new photos to for PhotoStructure to import them. This would be similar to PhotoPrism’s “Move Files” option for imports.
In Complex Setup with importer @Demosthenex suggested that move-on-import versus retain-on-import could be configured per-directory.
Does it make sense to follow the nomedia design pattern here, rather than encoding paths in a setting?
I’d like to keep the existing behavior as the default (as it’s the safest).
How would it be easiest to mark a folder to be delete-on-import mode? Just drop a
.delete-imported file or directory, just like
.nomedia? (I’d have to make sure this is ignored when found in the library directory!)
Another solution would be to support a “directory settings” file,
.photostructure.toml, that could contain overrides for filter and sync settings for all the files contained in that folder.
Also: what should happen to files in that directory that are already imported into the library? Should those be deleted as well?
I like this idea!
I like this idea even more! Either approach is fine, but having a directory settings file is more scalable as you can add extra options in the future.
If you can verify that the exact same image is in the library, I think it should be deleted.
And what would happen to any files that can’t be imported - those need left alone
That’s fine to keep as the default. I think you need to specify potentially destructive directories manually.
Needs to be configurable.
My opinion on the “no delete” is that PS is helping me deduplicate my photos into a safe and organized library. At some point I need to get rid of the old ones that are duplicates. Safely.
A timed or manual “trashbin” would make the most sense. Or even a trash folder, and direct the user to go remove those files themselves.
Do you mean a physical directory on the filesystem, or just a “delete-at” time in the future, stored in the database?
Yes, absolutely: PhotoStructure would only mark files for deleting if and only if the SHA of the file in the library matched the file outside of the library, and the delete-on-import setting (or the directory) was
Delete at time could be database.
“Move files to a folder for you to delete manually” is a physical directory.
I think this is a potentially dangerous but useful feature. IMO the best way to implement this is to ensure the user has to say yes like 5 times and even then PS should hang on to the photos “to delete” for one week or unless the user reviews the photos to delete (both visually and by photo name and location).
This takes from the concept of datasafe practices where the ultimate goal is data safety and data integrity as well as data availability.
But yes the ability to manage photo deletion could possibly be a good feature but IMO off by default. Would be horrible if the uninitiated accidentally started off their PS experience by deleting all of their photos
Deletion, while frightening, is a critical feature of any archival solution. Part of the reason we all have multiple duplicate copies of things is because we have tried to manage them repeatedly and never finished centralizing them. Archival and management requires careful deduplication of the inputs.
Yes, it (the feature) should be buried (ie: not a default). Alternatively moving the affected files to a place to be deleted by the user is quite direct. Unfortunately that’s in conflict with automation. Perhaps at the application layer, only NEW and empty directories could be setup to delete on import. I agree you never want to delete from existing locations without explicit understanding.
I agree, and yeah I’d be frustrated likely if I had to go manually delete them.
Thanks, @Demosthenex and @whoopn, for cogitating on this some more, that was helpful!
So: I think having a new
syncCopyHandler setting, with appropriate cautionary verbiage, should suffice here, that has 3 modes:
retain: Retain duplicate files (this is the current behavior and will be the default)
destroy: Immediately unlink all duplicate files during import
mark-deletable: Mark duplicates as deletable in the database (which can then be unlinked via a nav menu “empty trash” dialog).
I’ll update the delete topic with why I’m hesitant to support “hidden files” or system trash.
To my question about complex setups, these should be configurable by input directory.