search

pulsejet / memories

Fast, modern and advanced photo management suite. Runs as a Nextcloud app.
https://memories.gallery
GNU Affero General Public License v3.0
3.02k stars 79 forks source link

Archive photos (in external storage) via flag instead of moving them to .archive folder #828

Open eil047 opened 11 months ago

eil047 commented 11 months ago

Is your feature request related to a problem? Please describe. Moving photos around in external storage can create issues with permissions and conflicts with other applications that work on the same photo storage. E.g. an (external) backup/upload application can re-upload the same photos again - that have ‘disappeared’ (by Memories) to the .archive folder.

Describe the solution you'd like In my opinion the archive function should not induce a ‘physical’ move of the related files (in external storage) but should just set a flag that prevents the photos from showing up on the timeline and enables an archive filter view on the other hand. This is for me a more modern and universal approach (comparable with the creation of albums)

Describe alternatives you've considered I don’t / can’t use archiving now due to the above mentioned conflict with my external upload/backup application.

pulsejet commented 10 months ago

In my opinion the archive function should not induce a ‘physical’ move of the related files

This is by design (see https://github.com/pulsejet/memories/issues/681#issuecomment-1646966065). The point of archiving is not to "hide" but soft-delete the photos. In that sense, this is basically #805

eil047 commented 10 months ago

I understand this has been your design choice. I think however it is too intrusive and conflicting with the idea of sharing one common storage structure between several 'client' apps (Memories, Photoprism, Immich...). All 'interpretation by each app' should stay in the app and not affect the common storage.

I use archiving to hide the photos that I have put in albums - when I want to see these I go via the albums - they don't have to keep appearing also in my Timeline. But they should always remain in the basic year/month/day folder (search) structure. It's not like I want to put them in a Trash folder.

So maybe we need two buttons then: a 'soft-delete/trash' button and a 'hide from timeline' button?

pulsejet commented 10 months ago

See https://github.com/pulsejet/memories/issues/681#issuecomment-1763100818

I understand this has been your design choice. I think however it is too intrusive and conflicting with the idea of sharing one common storage structure between several 'client' apps (Memories, Photoprism, Immich...). All 'interpretation by each app' should stay in the app and not affect the common storage.

Just to add something, this is not the intended / common usage pattern. The opposite is, actually: that there should be a common understanding of what's happening across the apps as far as possible. This is one of the fundamental goals of Memories (see)

No Lock-In Memories stores most of the metadata in the EXIF headers of your photos, which means that you can easily migrate to other solutions without losing your data. It also utilizes your existing filesystem structure for organization without converting it to any specialized format.

So maybe we need two buttons then: a 'soft-delete/trash' button and a 'hide from timeline' button?

As I mentioned I'm fine with this or maybe an admin option to switch how archiving is done. But the performance needs to be acceptable.

MrRinkana commented 1 week ago

Yes this definitively seems like an incorrect way to set up things.

The folder that memories looks in as well as any other such as photoprism or immich must be the source of truth, meaning you trust that the files there will not get corrupted and have protections against accidental deletions and that also means that if a file is deleted/moved/edited there, it was intentional and should propagate, not be restored by some other source of truth.

Why would you want to archive in memories but not the other two?

If you want to host multiple frontends like photoprism, immich and memories from the same storage they must understand/accept what the others are doing. But I don't see how using multiple servers makes sense, multiple different mobile/desktop clients sure but why immich+prism+memories at the same time? That is asking for trouble. The way its described only makes sense to me if the thing that restores the images is the only place where the images are edited, and the rest just read only (but then the folder should be read only for the others)