I've used non-empty mountpoints a few times, mostly when mounting a directory onto itself, but I have no idea how popular that use case really is. Mounting to a new empty location is probably always possible, but it's sometimes quite undesirable or inconvenient: - Sometimes I want to enforce certain rules on a directory and hide the original directory to prevent confusion and misuse. - Sometimes I want to quickly test something on an existing directory, and a program I want to use might be configured or even hard-coded to use that specific directory. So I think this is worth fixing.
Here's my current understanding (I was a bit confused in my initial response): - The scope: bindfs seems to work fine with libfuse2 and fuse3 EXCEPT for `nonempty`. The test suite, which tests most other features, passes on Debian 10 with fuse3 installed. - The bug: libfuse2 checks that the destination is empty or `nonempty` is given. Then it invokes fusermount (symlinked to fusermount3), which doesn't accept `nonempty`. - bindfs cannot be compiled against libfuse3. That would require significant code changes. So it seems backwards compatibility between fusermount3 and libfuse2 was intended, and this is a bug there. If so, here are the "easy" fixes I can think of: 1. patch fusermount3 to accept and ignore `nonempty` (perhaps only when invoked through a symlink named fusermount?) or 2. patch libfuse2 to stop requiring `nonempty` (or passing it to fusermount when it's symlinked to fusermount3?) or 3. instead of symlinking fusermount -> fusermount3, make it a wrapper script that drops `nonempty` from any option list like `-o option1,nonempty,option2,...` If someone who knows FUSE better can point out something simple I can do in bindfs code instead, I'd be happy to write a short patch. But there may be other FUSE 2 filesystems designed to "wrap" an existing directory that also have this bug, so I think fixing this at the FUSE layer is better. On Tue, 18 Feb 2020 at 15:12, Eugene V. Lyubimkin <jac...@debian.org> wrote: > Hello, > > Martin Pärtel kirjoitti 17.2.2020 klo 10.49: > > I'm unfortunately unlikely to have time to port bindfs to FUSE 3 in the > near future :( > > > > The easiest distro-level workaround in terms of "least code required" > would probably be to patch fuse3's fusermount to > > allow and ignore `nonempty` (and maybe print a deprecation warning). Or > some hacks could probably be invented to direct > > FUSE 2 filesystems to use FUSE 2 helpers. It's up to the Debian > maintainers whether they want the maintenance burder of > > either of these workarounds. > > CC'ing FUSE's maintainer for extra input if any. > > > From the discussion above I gather that bindfs is still (with limitations) > usable with fuse3. If true, then I wouldn't > like to block users of fuse3 from using bindfs via strict Depends. I could > add Suggests or Recommends on fuse2, > though. > > How common of a use case is to use bindfs with a non-empty mount point? I > never mounted filesystems like that myself, so > I don't know if it's a minor nuisance with an easy workaround, or a > significant limitation making some use case > unachievable. > > > Regards, > -- > Eugene V. Lyubimkin aka JackYF > C++ GNU/Linux userspace developer, Debian Developer > >
