[ratorx]

The alternative behaviour seems undesirable too right? If you attempted to delete foo.txt in the merged filesystem and instead of deleting the file, it just replaced the contents (with b)

I think the behaviour makes sense. Otherwise deleting a shadowed file either requires extra state (to track whether to show the shadowed file after a deletion), or loses some of the implicit assumptions people make for filesystems (after I successfully rm, the file is gone).

[karlicoss]

Ah agree, your example makes sense!

I guess it ultimately depends on the usecase, I just gave the above as an easy to understand example. In my case I wanted something that merely merged multiple distinct directories as a unified view (just for convenience). Ideally they wouldn't be overlapping, but I was still a bit paranoid about this behaviour.

In addition had another confusion, the default policy for creating new files/directories was epmfs (create at the "most free space" partition). So as a result, when I created new directories/files, it seemed to do that seemingly at random.

Of course my bad, should have been a bit more careful, the man page/readme seem to explain it well :)

[lostmsu]

> loses some of the implicit assumptions people make for filesystems

This is sort of incorrect though. Unless your file system supports transactions (which I assume this one does not), this should never be your expectation.