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).
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?
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.
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 true.
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.
Just bumping activity on this one again. My use case for wishing for “delete on import” is a scenario of merging multiple separate libraries (previous organizational tool which left things to be desired) by the act of copying them into an import folder to be processed.
I already have a nightly rsync from the PS host to a backup NAS and from there to an off-site copy as well so keeping the “original” file structure doesn’t actually add any value, and I want to move it around anyway to get it off old hard drives, etc.
I completely agree that this should not be a default behavior and I can take or leave the “configurable by input directory” in my specific use case, but if you have multiple shares already in place then I can certainly see the need/value for it.
I assume such functionality waits for it’s place in the priority queue or similar?
