Open har0ke opened 2 months ago
Duplicate of "Film rolls are removed recursively" #16921
I'll ask the same questions I asked in #16921
When you try and remove a nested filmroll, how should it work?
Fail silently?
Refuse to give you the option to remove?
Fail with a message?
???
What should darktable do if you want to remove a nested filmroll?
It doesn't matter which solution you check, because it won't work for someone. The answer is there is no solution that can protect the user from themselves.
However, darktable does backup the database, so you can go to your ~/.config/darktable folder and rename the library.db and data.db files then choose a backup set and rename them to data.db and library.db then restart darktable and have your filmrolls back minus whatever differences happened between the backup and the problem.
Or, if you write sidecar files, you can just re-import each folder or recursive import the whole thing.
The backups and sidecars are how we try and protect the users from themselves.
Sorry for the duplicate, when searching for duplicates I did have "collections" and not "film-rolls" in my head...
Or, if you write sidecar files, you can just re-import each folder or recursive import the whole thing.
For me, the re-import work-around is currently not sufficient because of #16827.
When you try and remove a nested filmroll, how should it work?
Fail silently? Refuse to give you the option to remove? Fail with a message? ???
I still think this is counter-intuitive behavior, again, because in darktable the file system hierarchy is not really visible.
A minimum would be to warn the user that if more than the right-clicked film-roll will be affected. Then the dialog changes in formatting and it really is visible that something extraordinary is happening. A number that does not match the expected number of files, is hard to catch.
Also, having two separate options "remove..." and "remove recursively..." (or alternative wording) could give the users more flexibility and tells the user directly that more than files in that film-roll might be affected if he hits "remove recursively...".
For me, the re-import work-around is currently not sufficient because of https://github.com/darktable-org/darktable/issues/16827.
Then use the database backup.
Then use the database backup.
I already have.
This ticket was not intended as a support ticket but to suggest changing the unexpected behavior (in my opinion) or alternatively introducing another fail-safe or more explicit warnings to protect future users from making the same mistakes.
But if you are giving support here: Is it possible to re-import duplicate edits? The ones saved as "
When you import, darktable looks for all existing sidecar files for the image. You should be getting the duplicate edits automatically.
Just imported a fresh film roll, duplicated the first image twirce. Stopped darktable and removed all the database files. Opened darktable, reimported, and the duplicates showed up fine
Yes, I have not re-imported files that are in the last backup, but that I created duplicates for, after the backup. Thank you.
If you, unlike me, think this is the behavior as expected by the general user, you can close this issue.
Just so my suggestions do not get lost in the support discussion:
A minimum would be to warn the user that if more than the right-clicked film-roll will be affected. Then the dialog changes in formatting and it really is visible that something extraordinary is happening. A number that does not match the expected number of files, is hard to catch.
Also, having two separate options "remove..." and "remove recursively..." (or alternative wording) could give the users more flexibility and tells the user directly that more than files in that film-roll might be affected if he hits "remove recursively...".
If you, unlike me, think this is the behavior as expected by the general user
I would only not like you if you were rude. If you were rude, I would just leave the conversation. I'm still here :smile:
I understand your issue and don't disagree with your solution.
However, there are some facts you should be aware of:
I think that was a miscommunication. I meant: "If you, as opposed to me, think this is the behavior as expected by the general user, [....]". I was not intending to say that someone did not like me, nor trying to be rude myself. 😄
Also, I do not think this is issue is time-sensitive in nature. Thank you for your help.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
Describe the bug
If film-rolls are placed recursively on the file system, deleting a parent film-roll, will remove all child film-rolls recursively. This is counter-Intuitive, as in darktable film-rolls never show images from child film-rolls because file system hierarchy is typically not visible.
A basic example for a problematic file system layout:
My worst case example:
I have all my images under
/home/<user>/Pictures/Darktable
. If I temporarily open (and therefore implicitly import) a file from/home/<user>/
a new film-roll<user> (1)
is created, with a single image in that film-roll. Removing that film-roll from the library (right-click -> remove...) will now remove all images recursively, including all my primary film-rolls. This basically clears my whole database. The "remove images?" dialog that pops up actually tells you it is removing a huge amount of images, but some people (including me) might not read carefully enough.Steps to reproduce
<base_path>/A/a.jpeg
and<base_path>/A/B/b.jpeg
Film-roll "B (1)" is now also removed from darktable.
Expected behavior
Not remove film-rolls recursively.
Logfile | Screenshot | Screencast
No response
Commit
No response
Where did you obtain darktable from?
distro packaging
darktable version
4.6.1
What OS are you using?
Linux
What is the version of your OS?
Arch Linux
Describe your system?
No response
Are you using OpenCL GPU in darktable?
None
If yes, what is the GPU card and driver?
No response
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
No response