Logseq creates namespace page that doesn't exist and steals content from other page

(v0.3.3, Desktop, Windows)

I already postet some bug reports regarding namespace pages.

For this one I wanted to give you a specific bug report because it seems that Logseq is storing wrong informations from which you can’t even recover with a re-index and clearing the cache.

When I started to give namespace pages a try I created pages like JFx/Scrum but soon notices that I get into big troubles because I alread had pages like JFx.Scrum.

So I wanted to return to the state where I am NOT using namespace pages until those problems got solved. (Don’t try this - you are losing content!!)

The problem now is that:

  • I delete the JFx/Scrum namespace page
  • I clear the cache
  • I do a re-index
  • I close Logseq
  • now I recreate the page JFx.Scrum.md (simple markdown, nothing special, not title/alias property)
  • now I restart Logseq and …
  • on the file system I only have the file JFx.Scum.md with the content
  • in Logseq I see two pages “JFx.Scrum” (which is emtpy) and “JFx/Scrum” (which contains the content of JFx.Scrum.md)

I don’t know how I can recover from this state - Logseq must store the namespace page information somewhere - but I can’t get rid of this information.

Here is a screenshot too…

Just wanted to add, that I found a second page with that problem :slightly_frowning_face: and don’t know how many there are.

The fact, that I don’t know how to recover from this situation makes it quite critical. :zap:
An additional problem is, that I haven’t found a way to detect which pages have this problem.


I have at least found a workaround.

Let’s say I have one page that is named task.context.xy.md with some content.
This page generates two hits when searching:

  1. task.context.xy which is empty
  2. task/context/xy which contains the content

The way to recover from this problem is to…

  • open the file task.context.xy.md
  • and add a title in the first line

Something like: title:: task.context.xy

From then on only 1 hit is shown in the search and all links point to the correct page containing the content again.

So the problem is not so urgent for me anymore - but I still hope for improvements that make the handling more stable for such cases.