[karlicoss]

Cool tool, but recommend reading the policies [0] section carefully, it did catch me off guard the first time I tried using it.

E.g. say you have /a/foo.txt and /b/foo.txt, and you run mergerfs /a:/b /merged

Now if you print or modify /merged/foo.txt, it would access /a/foo.txt because the default policy for file access is ff (first-found, as defined during the mount).

However, if you run "rm /merged/foo.txt", it would delete it from both /a and /b, because the default policy for unlink call would be "epall" (existing path, apply to all).

[0] https://github.com/trapexit/mergerfs#policy-descriptions

[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.