Home / GitHub Page

Encrypted (using E2E) attachments after deletion

Joplin 1.0.170 (prod, Linux)
Android App 1.0.308

I successfully enabled E2E on all my devices (synced to a NextCloud instance).
Wanted to know how attachments are handled using E2E.
Created a test note and attached a small file to it.
Seems to work, I can see the encrypted note and the file in NextCloud/Joplin directory and the desktop program.
After deleting this note I waited for the sync on the desktop program completed successfully (the note and the attachment doesn’t show up anymore).

But I still can see the encrypted note (not the attachment!) in the NextCloud/Joplin directory.
On the Linux filesystem I still (even after multiple sync runs) can see two files in the ~/.config/joplin-desktop/resources directory:

What am I missing/doing wrong?

I don’t know if this applies for your case but here is a reference to resources being deleted after 48 hours.


1 Like

Thanks for this information!
I will just wait and look what happens in the next 2 days.

More information/observations:
Playing with the above mentined script on GH jnrmor I was surprised of the following output:

mw@NUC:~$ bin/jnrmor -n -d [debug] Using config file: /home/mw/bin/.jnrmor.conf [debug] Joplin database: /home/mw/.config/joplin-desktop/database.sqlite [debug] Web Clipper port: 41184 No orphaned resources found.

because IMHO there should be at least one orphaned resource.
After checking the options in joplin-desktop I found out that I had disabled notes history, which sets revisionService.ttlDays in the database to be empty. After enabling notes history again (setting it to 2 days) the script finds the orphaned resource file:

mw@NUC:~$ bin/jnrmor -d -n [debug] Using config file: /home/mw/bin/.jnrmor.conf [debug] Joplin database: /home/mw/.config/joplin-desktop/database.sqlite [debug] Web Clipper port: 41184 [debug] curl -s -X DELETE http://localhost:41184/resources/26af99a25f7249309c31338c532f8848?token=WEBCLIP_TOKEN Deleting resource id: 26af99a25f7249309c31338c532f8848

The found resource id corresponds to the filenames in the resource directory.
For now I still wait to see whether the orphaned resource will be deleted automatically…

@miwie Yep, a while back I adjusted the script to make sure there’s no data loss. (The note history feature was implemented after I created the script.) Thus it takes the note history into account.
Maybe I should have a look at what can be done when the note history is deactivated. The problem is that someone could deactivate it for a day/hour/minute and then activate it again. I have to think about that.

Btw, you shouldn’t post your token here. :wink:

OK, finally I decided to remove the orphaned resource file using the jnrmor script because it was not automatically deleted after waiting 2 days.