(Bug report) Loss of an irreplacable attachment - user error or bug?

[the-moog]

TriliumNext Version

0.90.8

What operating system are you using?

Other Linux

What is your setup?

Server access only

Operating System Version

Debian 12.8

Description

I wanted to work on a new version of a page, but did not notice it had children.

I used the 'Clone To' menu operation.
I think perhaps I don't understand what that is for and how it works, but using it lost two attachments in the form of pasted small images inline with text.

(Should point out that these are not a critical loss to myself. They can be re-created but the originals are irreplaceable. Also I do have offline backups that I can resort to if necessary but it's probably quicker to just re-create them.

After making some changes I then realised I'd 'cloned' a whole tree, rather than one page, so I just started deleting the unwanted cloned child pages.

Then I realised this had deleted not just the clones, but the originals too.

I tried to revert, that was fine . But any attempt to remove any part of the clone resulted in the original being deleted too.

I took a couple backups and then used the 'Duplicate Tree' function on the root of the original (not the clone), thinking at least I could preserve what was there independently and even if that failed, had a way to get back the same state
I then deleted entire clone which also deleted it's doppelgänger.

Today I re-visited the page to continue the edits and realised that a couple smell embedded images (which are impossible to replace) on that page have now have placeholders with a message "This image has been deleted". I assume they were not immediately 'deleted' as they would have been in the browser cache.

Before looking into the actual issue, in addition to the quad daily (but a faff to recover) disk backup there is the backup I did within Trillium.
Q: Is it possible, and if so how, to recover just the images (not pages) from the internal Trillium backup. If this would be more than 30mins then re-creating the images would be easier.

I am assuming one of two possibilities.

1: This is user error (but maybe a UI or doc error instead and even then may still related to another bug (3), below )
2: This is a bug and unintended behaviour

If the former. them perhaps the bug is in the naming of the operation. If this is not a clone, rather a 'reference' or 'shadow' then perhaps the word 'clone' is wrong, especially when right under a similar Clone/Copy.

If this is a bug, then perhaps the bug is related to how 'clones' are handled when there is also a 'duplicate' in that references within the duplicate are not also duplicated?

3: Even if it is user error, then I would argue that deleting a page should not delete it's mirror or any files that are linked to it, and instead only delete one of the multiple mirrors, exactly the same as a hardlink file in Unix, and perhaps even actually just that??
Is reference counting a thing for attachments? Even it it is, deleting a mirrored item should never touch any embedded items unless it is the very last one, and that same object is not used any place else. Even then do so with a very clear warning as to what will be lost not just that there is a a possibility of some loss.

Let me know if there is a way to restore my images, and/or if more information is required, or if there are any tests I can do to better understand what the issue actually is.

Error logs

No response

[meichthys]

Thanks for using Trilium (despite it's beta-ness)!
There's a lot here so I'll try to keep a running commentary:

I wanted to work on a new version of a page, but did not notice it had children.

I used the 'Clone To' menu operation. I think perhaps I don't understand what that is for and how it works, but using it lost two attachments in the form of pasted small images inline with text.

You can check here to read about clones, but yes, i think the issue here is that there's a misunderstanding on how clones work.
(We were actually just discussing today about re-working the wording of the the term 'clone').

(Should point out that these are not a critical loss to myself. They can be re-created but the originals are irreplaceable. Also I do have offline backups that I can resort to if necessary but it's probably quicker to just re-create them.

After making some changes I then realised I'd 'cloned' a whole tree, rather than one page, so I just started deleting the unwanted cloned child pages.

Then I realised this had deleted not just the clones, but the originals too.

This should not have deleted the originals unless you also checked this box:

I tried to revert, that was fine . But any attempt to remove any part of the clone resulted in the original being deleted too.

Assuming you didn't tick the checkboxes above, you should be able to restore using the Note Revisions dialog:

I took a couple backups and then used the 'Duplicate Tree' function on the root of the original (not the clone), thinking at least I could preserve what was there independently and even if that failed, had a way to get back the same state I then deleted entire clone which also deleted it's doppelgänger.

Today I re-visited the page to continue the edits and realised that a couple smell embedded images (which are impossible to replace) on that page have now have placeholders with a message "This image has been deleted". I assume they were not immediately 'deleted' as they would have been in the browser cache.

Before looking into the actual issue, in addition to the quad daily (but a faff to recover) disk backup there is the backup I did within Trillium. Q: Is it possible, and if so how, to recover just the images (not pages) from the internal Trillium backup. If this would be more than 30mins then re-creating the images would be easier.

You should be able to restore the backup, grab the images, and restore them to your existing instance. I would estimate this may take 10 minutes plus a bit of time understanding the backup/restore process.

I am assuming one of two possibilities.

1: This is user error (but maybe a UI or doc error instead and even then may still related to another bug (3), below ) 2: This is a bug and unintended behaviour

If the former. them perhaps the bug is in the naming of the operation. If this is not a clone, rather a 'reference' or 'shadow' then perhaps the word 'clone' is wrong, especially when right under a similar Clone/Copy.

I believe the former is true if the two checkboxes were ticked in the above screenshot. Clone is a bit of a loaded term, and what you probably wanted is the "Duplicate" feature. You would still need to delete the child notes since there is currently no way to duplicate a note without it's children. Feel free to file a feature request for this though. Perhaps we could have a "Duplicate Subtree" and a "Duplicate without Subtree" (or something similar)

If this is a bug, then perhaps the bug is related to how 'clones' are handled when there is also a 'duplicate' in that references within the duplicate are not also duplicated?

3: Even if it is user error, then I would argue that deleting a page should not delete it's mirror or any files that are linked to it, and instead only delete one of the multiple mirrors, exactly the same as a hardlink file in Unix, and perhaps even actually just that?? Is reference counting a thing for attachments? Even it it is, deleting a mirrored item should never touch any embedded items unless it is the very last one, and that same object is not used any place else. Even then do so with a very clear warning as to what will be lost not just that there is a a possibility of some loss.

I think what you want is the default functionality when deleting notes. The only way to delete all note clones is to check the checkbox(es) to do that. If this is not your experience, let us know and we can investigate.
The delete dialog does try to provide warnings when references are broken, but maybe it could be improved:

Let me know if there is a way to restore my images, and/or if more information is required, or if there are any tests I can do to better understand what the issue actually is.

I hope this helps!