Data loss due to conflict between namespace pages and existing pages

[ChrisVn]

I have already posted a question on this topic here:

Auto create pages and assign page-tags when using namespaces

@tienson Hi, could you please give a short statement if this would conflict with existing tags and pages that already use . (dot) as delimiter between “words”? I opened a specific discussion here: What I am not shure: If I already have tags like #task.project.topic1.subtopic or pages like [[BACKUP.task]] will these pages/tags generate also a corresponding [[BACKUP/task]] and #task/project/... page and tag or does it only work the other way around. Am I “safe” to continue using those dot-d…

and started a discussion here:

Is there a conflict of hierarchical tags with those that already contain a dot?

… or do I have to rename my previous tags? As far as I have noticed, there is a fairly new feature of naming pages hierarchically, for example [[books/science/topicXY]]. I do NOT use this feature yet. BUT, what I have been using for a long time are tags separated by a dot. For example [[BACKLOG.task]]. (and the dot is now the file-level separator for hierarchical tags). Now I have noticed that additional pages are automatically generated such as [[BACKLOG]] and [[BACKLOG/task]] which I have…

In my own tests, however, I have now found a critical behaviour that leads to data loss. I am therefore reporting the specific case here as a bug.

Initial situation:
There is already a tag #BACKLOG.task and therefore also a file with the name “BACKLOG.task.md”.

If the tag #BACKLOG/task/project-X/topic1 is created, the content of the file BACKLOG.task.md is overwritten.

Even after that, the situation remains critical, because in the search (even after re-indexing) #BACKLOG.task is found and displayed (as soon as “BACKOG.” is entered in the search). If you now open this page, you seem to land on the page with the title BACKLOG.task, but change the file BACKLOG.task.md although it has the title “BACKLOG/task” and thus overwrite the content of the file BACKLOG.task with the title BACKLOG/task.

The whole situation is confusing and unclear - and also critical because it leads to data loss.
I even deleted the contents of a specific BACKLOG/task/xy without knowing exactly why. The data was not really deleted - but apparently an inconsistent state is created:

• while the page: BACKLOG/task/xy is displayed empty (no content)
• but the file “BACKLOG.task.xy.md” exists with content but no title property.

After my tests I had to restore some files from my backup and from now on I stop my attempts with the namespace pages and hope for future changes that prevent data loss.

[Joe_Smoe]

What version? I ran into some problems with namespaces that were introduced in 0.2.10 which lead to me accidently deleting some content while trying to work-around the issue, so for now i’m staying on 0.2.8 until the fix is released. Tienson commented on my bug submission that this should be fixed in version 0.3.0 -> LS is creating two pages for namespaces · Issue #2500 · logseq/logseq · GitHub

[ChrisVn]

Thanks for your reply and sorry for the missing information.
I was using v0.2.10 (Desktop, Windows).

I will stay away from this feature until it get’s more stable and better documented. Looking forward to the new version.

[hcc108]

I am using the same version as well - and I have lost a few of my files because this namespace issues. What I found out was that for those with the first block being title:: ABC/XYZ the files are safe. But my old files without the title attribute get changed to ABC.XYZ. Then the file runs the risk of losing the data within it. I have lost a few files that way now. I hope a fix in underway…

[Ocarinalover]

is this issue still exist? this is a critical issue