Attachments lost again

A couple of times I have suspected that Joplin deletes file attachments that are not orphans - and now I have experienced it again.

I understand that Joplin regularly traverse through all attachments to see if they are not linked from any notes - and if they are not Joplin deletes the attachments.

I feel that this is a very dangerous behaviour - and i am beginning to think I can not trust Joplin to store important file attachments anymore.

The problem was discovered now with a note that I have kept for about 9 months now. Each month I add a new file attachment to the note. Now I suddenly discovered that 7 attachments of 8 has been deleted from this note. Only the newest attachment is still available.

Sync method is Dropbox. E2E encryption. My Joplin clients: Android, iOS, Win, Linux.

For me, it’s the other way around: Orphaned resources are not removed.

Your case is by far more serious than my problem, but maybe they are related somehow.

If you search for the resource IDs in your profile resources folder, can you find anything?

Also could you post here the part of your note that contains the resource markup?

Hi Laurent

This is the part of my note that contains the resource markup:

## Program:

[Program april 2019.pdf](:/4d81dd287cce451380ff94be114ecabb)

[Program mars 2019.pdf](:/8240e4d4268741918f331c5e82eea43f)

The first file opens fine. The second one seems to be lost.

Searching for the first file (which opens fine) on Ubuntu gives:

locate 4d81dd287cce451380ff94be114ecabb
/home/egil/.config/joplin-desktop/resources/4d81dd287cce451380ff94be114ecabb.crypted
/home/egil/.config/joplin-desktop/resources/4d81dd287cce451380ff94be114ecabb.pdf
/home/egil/Dropbox/Apps/Joplin/4d81dd287cce451380ff94be114ecabb.md
/home/egil/Dropbox/Apps/Joplin/.resource/4d81dd287cce451380ff94be114ecabb

Searching for the second file (which seems deleted when I click on it in Joplin) gives:

locate 8240e4d4268741918f331c5e82eea43f
/home/egil/.config/joplin-desktop/resources/8240e4d4268741918f331c5e82eea43f.crypted
/home/egil/Dropbox/Apps/Joplin/.resource/8240e4d4268741918f331c5e82eea43f

Thanks for all help!

Egil

Issue to track this: https://github.com/laurent22/joplin/issues/1433

Ok I’ve finally found what the issue was - it was a race condition between the encryption service and the resource service, which could affect notes that are often modified but with long periods of time between changes.

So these fixes have been made:

  • Added two test units to cover this case and make sure it won’t happen again.
  • Fixed the bug obviously
  • Added additional checks before deleting a resource to make sure it’s really not used in any note.

These changes should definitely make the resource management more reliable.

Thanks @eagle for providing the info that helped figure this out and sorry for the lost attachments! If you don’t have any other copy of these files left, I think they can be manually recovered from the artefacts left in Dropbox and your config directory. If you want to do that, let me know.

2 Likes

Hi @laurent

Thanks a lot for fixing this issue. I have gone through all notes and there are a few attachment that are gone that I do not have anywhere else… Is there a way I could recover them myself?

Thanks for all help!

The file that are left, for example “8240e4d4268741918f331c5e82eea43f” is basically the attachment you had. So if you know the file extension you can simply add it and it should open. For example if it’s a PDF, you rename it to 8240e4d4268741918f331c5e82eea43f.pdf. Unfortunately some metadata, such as the filename is lost.

Thanks @laurent

I am still a bit unsure on which file should be renamed. The one in local resources or the one in Dropbox sync folder.

In the example below - which file should I rename?

locate 8240e4d4268741918f331c5e82eea43f
/home/egil/.config/joplin-desktop/resources/8240e4d4268741918f331c5e82eea43f.crypted
/home/egil/Dropbox/Apps/Joplin/.resource/8240e4d4268741918f331c5e82eea43f

Thanks for all help!

Thanks, Eagle, for reporting this issue! Being able to trust that Joplin won´t loose any of my numerous attachments is critical to me.

Are there any checks I could take into my workflow to keep track on the state of my list of attachments - e.g. verifying any losses every time I make backup? My notes are encrypted.

Being able to do this would improve Joplin over the competition yet another step, actually.

The most reliable way to see what’s happening with your data in Joplin is to automatically setup a backup with git versioning as I’ve done there: Best method to backup notes

Another thing that will be happening soon is that notes will be versioned so even if something is deleted (even due to a bug), you’ll still be able to see the previous versions of the notes.

Excellent news!

Had the same problem, Now fixed… thank You

1 Like