/etc/fstab -> mount.fuse3 produces command lines incompatible with fuse_parse_cmdline

[lwoggardner]

Hi - I am currently rewriting the fuse bindings for Ruby and have come across this problem in testing.

/etc/fstab
myfs /mnt/myfs fuse3.myfs.rb debug
calls
mount.fuse3 myfs /mnt/myfs -t fuse3.myfs.rb -o debug
calls (via bin/sh -c)
myfs.rb myfs /mnt/myfs -o debug
which passes argv to fuse_parse_cmdline and gets
fuse: bad mount point myfs': No such file or directory

ie the first field (fsspec) in /etc/fstab becomes the optional "source" arg for mount.fuse3 and passed on to the filesystem executable which is incompatible with fuse_parse_cmdline that only expects one non-option arg - ie the mountpoint.

This is quite inconvenient because filesystem executables somehow have to know if they are being called via fstab/mount.fuse3 or called with fuse options directly.

I think fix is either

• fuse_parse_cmdline should handle the optional "source' field as sent by mount.fuse3
  OR
• mount.fuse3 should interpret that field and add -o fsname=

I'll probably handle this on the ruby side for now, for compatibility with existing fuse installations, but If I'm on the right track here I'm happy to create a PR.

[Nikratio]

I think adding better handling of options to mount.fuse3 would be the right way to address this. Thanks for reporting this.

[Nikratio]

Are you still interested in working on this?

[Nikratio]

I'm closing this issue for now. Please note that this isn't meant to imply that you haven't found a real bug or worthwhile potential improvement - you most likely have and I'm grateful that you took the time to report it.

Unfortunately, this project does not currently have any active, regular contributors. As the maintainer, I try to review pull requests and make regular releases, but unfortunately I have no capacity to do significant development beyond that.
Issue reports that do not come with a pull request or clearly have high impact on a large number of users are therefore likely to languish.

I understand that this is frustrating for users, but I hope you can also understand that any development work that I do on this project has to compete with spending time with my family, doing work that I get paid for, doing something recreational without a computer, or working on features/bugs that affect me personally. Most bugs and ideas - unfortunately including this one - loose out in this competition.

In other words, unless you plan to work on this yourself or can recruit someone who will, it's unlikely that anyone is going to do anything about it anytime soon.

Still, you may wonder why I am closing the issue rather than keeping it open.

In short, I want the issue tracker to show the most important issues that users should be aware of and where prospective contributors could make the biggest difference. I do not think there is much value in using it as an exhaustive database of every idea or glitch that someone has ever encountered - especially if no one is intending to address/implement it.

For this reason, I am closing most issues when it becomes clear that they're unlikely to see any activity in the near future - and this seems to be the case here.

I understand that you have invested time and effort in reporting this, and I am very sorry that currently there is no way to build upon this. I wish the situation was different.