deleting original child node when child has been linked to another parent deletes both

[vigilancetech-com]

go under parent A, create child header with "h," then go under parent B and link in that child with "c," then go back to parent A and delete that child and it also disappears from parent B.

I think it should act more like hard links in the Unix file system. The actual node doesn't get deleted until ALL the references (links) are deleted.

I know this will probably take reference counting or something to that effect but it seems inconsistent (and somewhat dangerous) as it currently is.

In fact, what I usually do with such systems is put everything new in a "hopper" folder then "hard link" it into all the other folders it needs to be in, then come back and delete the original. Org-brain's current behavior makes that impossible. And how is one to even really remember where the original location was (other than having to go to each parent the over to the org file to check out if its there or merely a reference to it is)?

I have not checked out if this works if each child was created as a separate file (but there are issues with doing all nodes that way, such as performance, difficulty of having to deal with potentially thousands of files, etc...)

[vigilancetech-com]

okay, now I just checked it with 'c' (create child as file). It works somewhat as expected, in that creating the child under parent A then referencing it under parent B then deleting it from A does not remove it from B but then if you delete the parent of A and B then re-create that parent, A and B show back up again and the child is still there unharmed under B. Seems like it should "prune" when you delete a parent. Also when I went to create the "grandparent" it was still there as an option under ivy.

This sounds like its going to eventually create a garbage collection problem.

[Kungsgeten]

I'm not quite sure I follow all the way, but I think the root of the problem is that all entries/nodes have a "physical" place where they're defined. Example:

* Fruit
** Banana

Here Banana is a child entry to Fruit, created as a child header (probably with h in org-brain-visualize). If you want to remove Banana from Fruit then Banana have nowhere to go. In org-brain we call Fruit the "local parent". However if Banana have another parent and you remove it from Fruit (using org-brain-remove-child) you should get a question if you want to change the local parent of Banana. Is that not the case?

[vigilancetech-com]

Well, that would possibly work, but it seems to me that the concept of "local parent" should be hidden in the background. Why would I care, as a user or org-brain, who was the local or remote parent to a node? I would just expect my node to not disappear because I deleted a link to it elsewhere.

How does "the Brain" software deal with such a thing?

[Kungsgeten]

I understand your concern, but the entries needs a "physical" place on the hard drive, if using org-mode. I think org-roam solves it by having each "entry" being a separate file, as does many other "Zettelkasten" systems. My guess is that The Brain soves it by having a database containing all of the info. org-brain doesn't have a database (but org-roam does).

From a point of usability I think your concerns are valid, but it may also be dependant on how you use org-brain. Some users almost exclusively interact with org-brain via org-brain-visualize, while others also visits the files/entries in org-mode and edit there, then the "locality" probably makes sense if you're coming from org-mode without org-brain.

My tip would be to use "c" to create children instead of "h" if you don't care about the appearance of the org-mode files. If you don't want a separate file for each new "root" entry you can set org-brain-default-file-parent to a file where you want the new entries to show up. You can then tag that file entry with nolocalparent and the file itself will not be considered an entry by org-brain, and thus it is not a parent of the headlines in the file.

[vigilancetech-com]

How can I use c to create the items one per file but have org-brain include a single header in each so I can attach files to them?