Backup Filenames when syncing with Mega

[Nicole_Daniella (Nicole Daniella Murillo)]

Not exactly sure if this should actually belong here as it’s more of a question than big issue, just want to have my bases covered.

Situation

I’ve had a couple of situations where I’ve included a screenshot on a note only to have it disappear later on, not exactly sure why that happens, but I know it does and because of this situation I try to rarely add any screenshots.

I remember that in a previous occasion, it was suggested that I check on the backup if the image existed, which it didn’t. I have backup enabled and have the files placed on a directory that is synced via Mega (mega.nz) and just noticed that I have files named as

./data/note:KkrWqDKrzN.json
./data/note%3aKkrWqDKrzN.json

Those are two files that are exactly the same, however, that only happens when an update causes for the backup to occur, since there are some instances where only the version with %3a exists.

I believe that the sync process with Mega is changing the colon ( to the %3a and believe that this might cause an issue, but there’s where my question is.

This change in the name would prevent Inkdrop from restoring the files? Which appears that it might have an issue, since there are copies of the same files given the name difference.

Should I consider moving the files to another sync service that doesn’t rename them this way?

Info

• Platform: Linux
• Platform version: Arch rolling (up to date)
• App Version: 5.2.1

Reproduce

Configure the backup to a folder that is synced via the Mega service using their sync application.

[craftzdog (Takuya Matsuyama)]

Hi Nicole,

Thank you for the question.
It seems to be the same issue as this topic:

`:` is not supported in OneDrive, Amazon Drive, or Sync.com

Is there a way to restore the backup on launch? This would be very helpful to me! I just want a prompt that asks if I want the JSON restored whenever I launch Inkdrop.

As Inkdrop uses : for its document IDs, it also uses the character in the backup filenames.
So, it assumes that you have a set of backup files with correct filenames, not being url-encoded like %3a.
I was testing it with Dropbox and Google Drive and found that they worked fine with those filenames.
But it turns out recently that other cloud storage services don’t deal with special characters very well, unfortunately.

So, the answer is yes. Please use Dropbox or Google Drive to sync your backup for now.
I’ll continue the discussion on the above topic.

[Ryan_McQuen]

@Nicole_Daniella, as somewhat of a workaround, you can use my plain text backups plugin:
https://my.inkdrop.app/plugins/plain_text_backups