Getting attachment conflicts when replacing resources using filename

[jdtang13]

UPDATE: The root cause I think is that attache basically updated all the attachment ids, rather than using the old attachment ids. this is a glitch and prob the edge case needs to be patched somewhere.

Hello, I am getting attachment conflicts when replacing the resources using filename.

I see that the attachment is successfully uploaded to cloud, and also that the Tools > Note attachments view is using the updated attachment id now, but the ORIGINAL NOTES are still using the old attachment id which causes placeholder thumbnail to show up and not the real image.

I am using Joplin 2.9.17 and latest version of this plugin. Thanks

[jdtang13]

This part of the readme is confusing to me: Again, your Notes have NOT been updated in any way, the placeholder icon in preview will now show your replacement resource :)

If the notes haven't been updated, then it seems like they will use the old resource id, not the new resource id.

[jdtang13]

https://discourse.joplinapp.org/t/plugin-replace-resources/21706

Note: due to Joplin's synchronisation conflict safeguards, this is a two-step automated process, first deleting resources and starting synchronisation for you, followed by posting (creating) resources using the original resource id.

OK, I see, so the problem is that the original plugin was supposed to use the original resource id. However, somehow, when I used it, it creates a NEW resource id that doesn't match with the old one.

[graphit0]

Hello there,

I just tested the filename replacement using Joplin 2.10.6 and Attache 1.1.1

It works alright for me. Meaning it does replace old resource with a new one without changing its ID. Therefore the modification dates are preserved.

Could you describe step by step what have you done and at what point the problem arises? Also recording might be helpful if you can do it

[jdtang13]

Hi, I'm currently wiping everything so I can't repro the issue from scratch right now. But one characteristic was that it involved 8000+ items, and also I continued using Joplin a few times during the initial sync, i.e. updating notes here and there, which maybe interrupted some procedures.

Anyways, aside from the large volume and updating a few notes (<10 times) I followed instructions in the readme.

[graphit0]

I can't say for sure but my guess is that Attache isn't designed to handle interruptions really well... But based on your user story we could come up with a test case to allow interruption handling in this specific case. So, if you ever experience this defect on smaller scale or could generate reproduceable behaviour, please post it

[jdtang13]

To be honest, I am still struggling with recovering the previous status of my notes after this. It affected over 8000 images. I was able to use "rewind" on the "resources" folder in dropbox, but i cannot "rewind" the notes themselves since dropbox can't handle the volume.

Even after rewinding the resources folder, many of the notes are still broken, and I think it's because they are using the updated attachment ids, which are broken.

The high level question could be how to revert the updated attachment ids to the "old" original id, also if those ids are generated randomly every time or if its deterministic based on the content of the original file.

Any help is appreciated, thanks!

[graphit0]

If youve got another desktop client on other computer and havent synced it, you can export a .jex backup and restore it back again on your main profile.

Additionally, if you've got note history enabled you might be able to revert previous versions. Not sure if it can be done in bulk without writing any scripts tho

[jdtang13]

I have a mobile client that's partially unsyncd, would that work? Didn't see any option to upload it back though

No, I don't have a desktop client backup sadly

So I just double checked actually and the problem is that the old notes are the same but the "attachment registry" (Tools > Note Attachments) has been updated with new ids.

For example, in Tools > Note Attachments

107e26a569f9c4348e2e0a916f530c21.png 7.93 kB 737011cb34474b008ddbdd5a638e2e6f <--- working, but wrong unique id

Old note:

107e26a569f9c4348e2e0a916f530c21.png (:/e20b74eb944d48c3be996bf250483347) <-- same filename, original unique id

So if there's a way to revert the attachment registry somehow that might be better

Thanks

[jdtang13]

The root cause I think is that attache basically updated all the attachment ids, rather than using the old attachment ids. this is a glitch and prob the edge case needs to be patched somewhere.

[graphit0]

Mobile profile export could potentially work but i can't promise anything since i havent done the profile restoration myself, only seen people discussing it on the forum.

Mobile -- Configuration -- export profile

The most important file here is sqlite database since it holds the resource registry. So you might try applying it on desktop.

However, please from now on backup every significant change of your profile so you wouldn't brick your profile even worse.

Personally i don't know how to work with resource registry, so i'll stay away from advising anything, but our forum and github is quite rich on all sorts of problems. So you may have a look there

[jdtang13]

Yes, I will backup everything from now on. I actually checked and I do not think iOS has the export profile option. Am I mistaken

[graphit0]

I don't own an iphone but the button should look like this

[jdtang13]

Yeah, seems we don't have that on ios atm

[graphit0]

At this point i'll throw the towel.

Please post your situation in fullest detail possible on the forum so more than 1 person could read it 😅

If i suddenly come up with an idea, i'll leave the comment there

[jdtang13]

Sure,I will post

[jdtang13]

Thanks for help so far

[manuerwin]

Hi JT, Happy to work on patching this however unsure how to reproduce, are you able provide any more info?

Thanks graphit0 for jumping in :) 👍

On Mon, 27 Feb 2023 at 11:41, JT @.***> wrote:

Thanks for help so far

— Reply to this email directly, view it on GitHub https://github.com/manuerwin/joplin-plugin-attache/issues/15#issuecomment-1445487644, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHPZDR6JOLFWJ7REZHCU7LWZPLZXANCNFSM6AAAAAAVIBQVC4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jdtang13]

Hi @manuerwin , thanks for taking a look, I am using the aforementioned version of Joplin (2.9.17) and I performed these steps: 1) copy ~8000 resource photos from local joplin-desktop/resources to my-new-folder 2) set the destination in Attaché plugin to my-new-folder 3) enable "use Attache on app start and sync" 4) start Attache, see that 8000 resource items are being deleted 5) continue using Joplin normally (creating and modifying notes, etc) 6) see 8000 resource items being created 7) finish, see that all photos now have "placeholder" preview icon, and id's in the notes don't match anymore with Tools > Note attachments menu 8) broken state

[graphit0]

As a sanity check, if you manually place the correct original id into currently broken link (in a note) to a resource, would it open fine?

[jdtang13]

Yes. For example, old note says this, and it is broken

![f8d2d854317ad457b096ac99b9ff86e7.png](:/fbcef43cc69948afb8fadb7597327dde)

Now, I look up this file name in Tools > Note attachments to get the mapping. The mapping says:

f8d2d854317ad457b096ac99b9ff86e7.png 38.3 kB 54b3ea20efee45ae992155c43df2301c

So now I replace it like this:

![f8d2d854317ad457b096ac99b9ff86e7.png](:/54b3ea20efee45ae992155c43df2301c)

and it works

[graphit0]

Ok, I'll inquire about find and replacement tool in batch from the creator of utils.

My idea is that by replacing the list of wrong ids for correct ids, hopefully you could restore your database back to normal. Text you later

[jdtang13]

Thanks graphit0, also I posted it on community: https://discourse.joplinapp.org/t/attachment-ids-no-longer-match-between-notes-and-joplin/29805

replacing the list of wrong ids for correct ids, hopefully you could restore your database back to normal

That sounds pretty systematic and I think it would work well in this case

[manuerwin]

I was never able to reproduce this, however have added a number of warnings in documentation and in-app advising users to not touch Joplin while replacements are happening.