Multiple Files in Hierarchical Folder Structure doesn't directly open attachments

[metal450]

When using a single-file database & opening an attachment, CherryTree warns you before quitting: "Temporary files were created and opened with external applications. Quit the external applications before quit CherryTree". That makes sense: since the attachments are embedded in the database itself, they have to be extracted somewhere to be edited, & then re-imported before CherryTree quits (or the edits will be lost).

One of the primary motivations in requesting "Multiple files in hierarchical folder structure" was that this would no longer be necessary: since all the attachments would then be stored directly on disk, double-clicking them can just open those files directly - thus you could quit CherryTree & continue editing them. It was the 3rd bullet in this issue: #1823:

"No risk of data loss when editing an attachment, as you're just editing directly on disk (i.e. even if you close CherryTree before saving the external edit, your editor just saves directly to disk)."

Also the last bullet in this follow-up: #1823 (comment)

"When opening an attachment, open the file in that directory. External file is edited directly, so saving the changes there is sufficient (no need to save the changes in the external editor, & then save changes in CT - could even quit CT while the external editor is still opened, & all will be good)."

However, I noticed that even with the new multi-file storage, CherryTree still shows this warning...and upon testing...it looks like it's actually not directly opening the attachments on disk. If I quit CherryTree and then save the attachment, no file in the "Hierarchical Folder" is modified, and the changes are lost.

Also, if I open an attachment, edit it, save, then save in CherryTree, it deletes the previous attachment & creates a new one. This also invalidates the 2nd bullet (motivation) in #1823:

"external backup software can see which attachment changed & needs to be versioned"

Because the attachment is deleted & created with a new name, rather than edited, external backup software can't identify it as an edit for the purpose of versioned backup.

All that is to say: when using multi-file storage, can we just have CherryTree directly launch the attachment in-place, so all the above benefits are realized?

[Kansai53]

It would also be nice if the separate files+folders were named in a way that they could be identified on disk. i.e. rather than just hashes, attachment filenames could be hash-attachmentname. And likewise, rather than the node folders being just numbers, they could be number-nodename. Then the tree could actually be interpreted on-disk if needed.

[metal450]

I realized that this also doesn't allow syncing software to benefit from block-level transfer. Since whenever you edit an attachment, it doesn't actually edit the attachment - rather it deletes the old file & recreates a new one with a different name. Thus the sync software thinks it's an entirely new file, and must transfer it in its entirety.

It would be much better if the attachments could be named as they are in the content, and when you edit them, it simply edits them directly on disk.

[metal450]

@giuspen any way you'd consider bumping this to the front of the queue if I were to send over a donation to motivate its development? :)

I totally understand CT is FOSS & there are tons of asks, so I'd be happy to contribute some sats if it could mean getting this done. Was super excited when #1823 was marked as resolved (it was my most eagerly awaited issue since 2021), but actually found that it didn't quite address the issues I was hoping.

Thanks again