Dear Maintainer,

As I reported[1] to the rb-general mailing list recently, there is a quirk in
the behaviour of FUSE filesystems relating to removal of currently-open files;
they are not deleted from the underlying filesystem by default, but instead
are renamed to a temporary dotfile name.  This can cause unexpected results,
such as failures to remove a directory that is expected to be empty.

I'd like to suggest that we enable the FUSE 'hard_remove' option by default,
which will propagate the removal operation directly to the underlying
filesystem.

One word of caution, though:

There _is_ a note[2] in the FUSE documentation that the option is not
recommended, because subsequent operations on unlinked (removed) files will
fail.  Perhaps that side-effect would produce other, more significant failure
cases that are trickier to deal with.

I plan to open a merge request on upstream Salsa with a test case to
demonstrate the problem, and a modification to enable hard_remove that resolves
it.

Regards,
James

[1] - https://lists.reproducible-builds.org/pipermail/rb-general/2025-January/003637.html

[2] - http://libfuse.github.io/doxygen/structfuse__config.html#af32ff56fa1131da899756cc352718101