Handle bind mount of directory that already has content about impermanence

[willbush]

Looked into this a bit more and realized it's not deleting anything.

~/tester
❯ tree -a
.
├── a
│   └── test.txt
└── b

3 directories, 1 file

~/tester
❯ sudo mount -v -o bind ./b ./a
mount: /home/will/tester/b bound on /home/will/tester/a.

~/tester
❯ tree -a
.
├── a
└── b

3 directories, 0 files

~/tester
❯ sudo umount ./a

~/tester
❯ tree -a
.
├── a
│   └── test.txt
└── b

3 directories, 1 file

When using bind mount (mount -o bind) a directory (./b) to another directory
(./a), the contents of ./a are "hidden", and instead, the contents of ./b
become visible within ./a.

In my case, tmpfs root, the data is actually only lost when rebooting.

I still think there should be an error message though. Perhaps a check can be added to create-directories.bash?

Perhaps a more robust solution would be to move the data into /tmp and then back after mounting?

[KFearsoff]

Yes please. The current behavior of silently bind mounting is not convenient or obvious.

Apparently, there's a project that automates persisting: https://github.com/Geometer1729/persist-retro . I think this is not the best approach, and we should just throw an error if the directory is detected. The reason for that is there might be running processes that are working on the folder already. Unless we can figure out a heuristic that helps us not break running processes while moving the contents, we shouldn't do that.