Some Tag Directories are Unrecognised/Inaccessible

[MirisWisdom]

Problem

Some of the directories in ~/notes/tags aren't recognised as directories (or even files). They show up when invoking ls -l, albeit with no form of metadata attached to them:

root@grml ~/notes/tags # ls -l
ls: cannot access 'notes': No such file or directory
ls: cannot access 'diary.2019.12': No such file or directory
ls: cannot access 'diary.2020.02': No such file or directory
ls: cannot access 'diary.2020.03': No such file or directory
ls: cannot access 'notes.exercise': No such file or directory
total 0
drwx------ 2 root root 30 Nov 18 23:08 diary.2019.04
drwx------ 2 root root 31 Sep 29  2019 diary.2019.05
drwx------ 2 root root 30 Sep 29  2019 diary.2019.06
drwx------ 2 root root 31 Sep 29  2019 diary.2019.07
drwx------ 2 root root 31 Sep 29  2019 diary.2019.08
drwx------ 2 root root 30 Sep 29  2019 diary.2019.09
drwx------ 2 root root 36 Sep 30  2019 diary.2019.10
drwx------ 2 root root 30 Nov  8 21:04 diary.2019.11
?????????? ? ?    ?     ?            ? diary.2019.12
drwx------ 2 root root  3 Jan  1  1970 diary.2020
drwx------ 2 root root 31 Jan  3 20:32 diary.2020.01
?????????? ? ?    ?     ?            ? diary.2020.02
?????????? ? ?    ?     ?            ? diary.2020.03
drwx------ 2 root root  7 Apr  5 23:18 diary.2020.04
?????????? ? ?    ?     ?            ? notes
drwx------ 2 root root 16 Sep 10  2019 notes.admin
?????????? ? ?    ?     ?            ? notes.exercise
drwx------ 2 root root  5 Oct 26 01:58 notes.software
drwx------ 2 root root 12 Jan  1  1970 notes.work

Notice the question marks and cannot access [...] no such file or directory errors.

Tags show up and work absolutely fine in the regular SN client, even after clearing the data and importing a backup.

[MirisWisdom]

Solution

The night's long, and the hair's grey. The cause? Tags referencing notes without any UUIDs:

{
  "uuid": "660f566e-3a95-4f6d-8713-9df1df8e07ab",
  "content_type": "Tag",
  "created_at": "2020-03-16T18:47:44.618Z",
  "updated_at": "2020-04-06T18:25:11.761Z",
  "content": {
    "title": "notes.exercise",
    "references": [
      {
        "uuid": "301db4ed-57d7-4265-b95a-adaa63e68546",
        "content_type": "Note"
      },
      {
        "content_type": "Note" //THIS.GUY.HERE.LACKS.AN.UUID
      }
    ],
    "appData": {
      "org.standardnotes.sn": {
        "client_updated_at": "1970-01-01T00:00:00.000Z"
      }
    }
  }
},

The solution is to remove members of a tag's references property which lack an UUID.

[tannercollin]

Thank you for your investigation!

@mobitar any idea how a note reference could end up lacking a UUID? How do the official clients handle this?