Bug report: different note ids after restoring from backup

Beta Beta Bug Reports
1

Testing version:
2.1.8

What were you doing:
I was restoring from a backup.

What feature did you use:
I have a lot of links to specific bear notes that I use in other apps, e.g., in Things 3. The links are of the following form: bear://x-callback-url/open-note?id=41C51FB9-CF18-4CC0-82FA-69D608A73BA4

What happened:
Upon clicking the link, Bear opens, but the note cannot be found. After further investigation, it turns out that all note ids are not the same anymore. I.e., restoring from the backup changed the note ids of the notes in the backup.

What did you expect to happen:
I expect ids to be persistent through all actions, including restoring from backups. With the current behavior, linking to notes and occasionally using the backup feature does not make sense, as it breaks all links.

1 Like
2

I experienced the same issue, but luckily didn’t have many links from outside apps.

I also cannot understand why a complete restore can’t reuse the original identifiers that are present in each note’s info.json, included in every .textbundle in the zipped backup file:

"uniqueIdentifier" : "D1B7C8B2-A940-4CCF-A93B-BF6D0A2BA23C"

info.json:

"net.shinyfrog.bear" : {
    "lastEditingDevice" : "RMBP",
    "archivedDate" : null,
    "modificationDate" : "2019-11-17T07:16:45Z",
    "trashed" : 0,
    "pinnedDate" : null,
    "creationDate" : "2019-11-17T07:16:45Z",
    "trashedDate" : null,
    "uniqueIdentifier" : "D1B7C8B2-A940-4CCF-A93B-BF6D0A2BA23C",
    "archived" : 0,
    "pinned" : 0
  },
  "version" : 2,
  "type" : "net.daringfireball.markdown",
  "creatorIdentifier" : "net.shinyfrog.bear",
  "transient" : false
}
  • Is this a bug?
  • Doesn’t the restore function clear the database as first step of restore?
  • Are the identifiers maybe generated internally by the database, and not by the restore function?
  • Could this be changed or fixed sooner than later?

@trix180 Do you mind clarifying on this issue? Thank you :slight_smile:

2 Likes
3

Hello,

this is intended because the same UUIDs are used for the sync. Backup restoration is supposed to reset the online status, but using the same UUID may lead to issues because of how CloudKit and our sync are conceived. The UUID in the backup’s single files is used to change the internal note-linking when a backup is restored. Unfortunately, this applies only to the note links in Bear and not to external apps.

Theoretically, we can overcome this limitation but means heavily changing the sync and potentially generating more issues. Also, this doesn’t seem to be an issue for many.

2 Likes
4

Hmm, I realize that changing the sync is probably too much work. Maybe you could consider one of the following solutions?

  1. “Copy Link To Note” could also contain the title of the note. This way, even if the link breaks, it would still be possible to find the note. With only the id, this is impossible. Notion is doing something similar. The following link first contains the page title, then the id. Internally, only the id is used: https://www.notion.so/workspacename/demo-page-4ca195a602cd4d64ba0df2060350ea43

  2. Store a mapping between old and new note ids. This way, when the note id changes, the old id could still be used to find the note.

3 Likes