Re: fuse - bindfs, fuse-zip, strange issues
On Sat, Jun 14, 2014 at 01:33:24PM +0100, Stuart Henderson wrote:
> "what is implemented" - sure, see /sys/miscfs/fuse and /usr/src/lib/libfuse ;)
> These in particular:
>
> fuse.c: FUSE_OPT_KEY("-h", KEY_HELP),
> fuse.c: FUSE_OPT_KEY("--help", KEY_HELP),
> fuse.c: FUSE_OPT_KEY("-ho",
> KEY_HELP_WITHOUT_HEADER),
> fuse.c: FUSE_OPT_KEY("-V", KEY_VERSION),
> fuse.c: FUSE_OPT_KEY("--version", KEY_VERSION),
> fuse.c: FUSE_OPT_KEY("max_read=", KEY_MAXREAD),
> fuse.c: FUSE_OPT_KEY("debug", KEY_STUB),
> fuse.c: FUSE_OPT_KEY("-d", KEY_STUB),
> fuse.c: FUSE_OPT_KEY("-f", KEY_STUB),
> fuse.c: FUSE_OPT_KEY("-s", KEY_STUB),
> fuse.c: FUSE_OPT_KEY("use_ino", KEY_STUB),
> fuse.c: FUSE_OPT_KEY("default_permissions", KEY_STUB),
> fuse.c: FUSE_OPT_KEY("fsname=", KEY_STUB),
>
> "what is not" - there are several implementations of fuse with different
> capabilities, so compare the above with these ..
>
> Linux, see "General mount options" in e.g.
> http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html
>
> fuse4bsd (FreeBSD), see "struct mntopt mopts" in
> http://mirrors.rit.edu/zi/fuse4bsd/498acaef33b0.tar.gz
>
> > I would expect `mount' output would show source in the output.
>
> I guess you mean you're expecting it to show "fsname"..? (in linux
> this defaults to the program name mounting the filesystem though can
> be changed with a mount option). - fsname isn't implemented yet
> (stubbed out).
>
> > # sysctl kern.version
> > kern.version=OpenBSD 5.5-current (GENERIC.MP) #202: Fri Jun 13 12:56:14 MDT
> > 2014
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > # fuse-zip /home/jirib/tmp/logs.zip /mnt
> > # mount -v -t fuse
> > fusefs () on /mnt type fuse (rw, local, ctime=Sat Jun 14 12:18:36 2014)
> >
> > With latest amd64 snapshot 'bindfs' even stop working :/
> >
> > # bindfs /home/jirib/tmp /mnt
> > fuse: unknown option allow_other
>
> Not implemented. allow_other is not expected to be accepted by our
> fuse implementation yet.
>
> > ^^^ google reveals some /etc/fuse.conf
>
> OpenBSD libfuse doesn't support /etc/fuse.conf.
>
> > # bindfs -d /home/jirib/tmp /mnt
> > fuse: unknown option -d
>
> This is something to do with the fact that it's setting up its own
> options array and calling fuse_opt_parse with that, but I got a bit lost
> in fuse_opt_parse / parse_opt.
>
> btw, your port is not really ugly, but s/GPLv2/GPLv2+/, and the do-install
> doesn't seem to be useful. But it looks like it relies on quite a lot of
> things that are not supported in OpenBSD's fuse implementation.
Thanks for explanation Stuart. As I'm not a programmer than
I will maybe try to resurrect to make bindfs run on OpenBSD
when OpenBSD FUSE implemantation would get more features.
jirib
Re: fuse - bindfs, fuse-zip, strange issues
On 2014/06/14 06:30, Jiri B wrote:
> On Sat, Jun 14, 2014 at 09:17:19AM +, Stuart Henderson wrote:
> > On 2014-06-14, Jiri B wrote:
> > > Huh, is this fuse really ready to use? I'm running this
> >
> > It's working fairly well for programs that only use the implemented
> > features,
> > but some newly ported programs need extra features adding to the
> > kernel/library.
>
> Ah, is it written somewhere what is and what is not implemented?
"what is implemented" - sure, see /sys/miscfs/fuse and /usr/src/lib/libfuse ;)
These in particular:
fuse.c: FUSE_OPT_KEY("-h", KEY_HELP),
fuse.c: FUSE_OPT_KEY("--help", KEY_HELP),
fuse.c: FUSE_OPT_KEY("-ho", KEY_HELP_WITHOUT_HEADER),
fuse.c: FUSE_OPT_KEY("-V", KEY_VERSION),
fuse.c: FUSE_OPT_KEY("--version", KEY_VERSION),
fuse.c: FUSE_OPT_KEY("max_read=", KEY_MAXREAD),
fuse.c: FUSE_OPT_KEY("debug", KEY_STUB),
fuse.c: FUSE_OPT_KEY("-d", KEY_STUB),
fuse.c: FUSE_OPT_KEY("-f", KEY_STUB),
fuse.c: FUSE_OPT_KEY("-s", KEY_STUB),
fuse.c: FUSE_OPT_KEY("use_ino", KEY_STUB),
fuse.c: FUSE_OPT_KEY("default_permissions", KEY_STUB),
fuse.c: FUSE_OPT_KEY("fsname=", KEY_STUB),
"what is not" - there are several implementations of fuse with different
capabilities, so compare the above with these ..
Linux, see "General mount options" in e.g.
http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html
fuse4bsd (FreeBSD), see "struct mntopt mopts" in
http://mirrors.rit.edu/zi/fuse4bsd/498acaef33b0.tar.gz
> I would expect `mount' output would show source in the output.
I guess you mean you're expecting it to show "fsname"..? (in linux
this defaults to the program name mounting the filesystem though can
be changed with a mount option). - fsname isn't implemented yet
(stubbed out).
> # sysctl kern.version
> kern.version=OpenBSD 5.5-current (GENERIC.MP) #202: Fri Jun 13 12:56:14 MDT
> 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> # fuse-zip /home/jirib/tmp/logs.zip /mnt
> # mount -v -t fuse
> fusefs () on /mnt type fuse (rw, local, ctime=Sat Jun 14 12:18:36 2014)
>
> With latest amd64 snapshot 'bindfs' even stop working :/
>
> # bindfs /home/jirib/tmp /mnt
> fuse: unknown option allow_other
Not implemented. allow_other is not expected to be accepted by our
fuse implementation yet.
> ^^^ google reveals some /etc/fuse.conf
OpenBSD libfuse doesn't support /etc/fuse.conf.
> # bindfs -d /home/jirib/tmp /mnt
> fuse: unknown option -d
This is something to do with the fact that it's setting up its own
options array and calling fuse_opt_parse with that, but I got a bit lost
in fuse_opt_parse / parse_opt.
btw, your port is not really ugly, but s/GPLv2/GPLv2+/, and the do-install
doesn't seem to be useful. But it looks like it relies on quite a lot of
things that are not supported in OpenBSD's fuse implementation.
Re: fuse - bindfs, fuse-zip, strange issues
> Attaching my _ugly_ (WIP) port of bindfs :) > > j. > > [demime 1.01d removed an attachment of type application/x-tar-gz] https://github.com/jirib/openbsd-mystuff/tree/master/sysutils/bindfs j.
Re: fuse - bindfs, fuse-zip, strange issues
On Sat, Jun 14, 2014 at 09:17:19AM +, Stuart Henderson wrote: > On 2014-06-14, Jiri B wrote: > > Huh, is this fuse really ready to use? I'm running this > > It's working fairly well for programs that only use the implemented features, > but some newly ported programs need extra features adding to the > kernel/library. Ah, is it written somewhere what is and what is not implemented? I would expect `mount' output would show source in the output. # sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #202: Fri Jun 13 12:56:14 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # fuse-zip /home/jirib/tmp/logs.zip /mnt # mount -v -t fuse fusefs () on /mnt type fuse (rw, local, ctime=Sat Jun 14 12:18:36 2014) With latest amd64 snapshot 'bindfs' even stop working :/ # bindfs /home/jirib/tmp /mnt fuse: unknown option allow_other ^^^ google reveals some /etc/fuse.conf # bindfs -d /home/jirib/tmp /mnt fuse: unknown option -d Attaching my _ugly_ (WIP) port of bindfs :) j. [demime 1.01d removed an attachment of type application/x-tar-gz]
Re: fuse - bindfs, fuse-zip, strange issues
On 2014-06-14, Jiri B wrote: > Huh, is this fuse really ready to use? I'm running this It's working fairly well for programs that only use the implemented features, but some newly ported programs need extra features adding to the kernel/library. > kern.version=OpenBSD 5.5-current (GENERIC.MP) #126: Mon May 12 22:40:04 MDT > 2014 > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP That's a little old, there have been fixes since then.
fuse - bindfs, fuse-zip, strange issues
Hi, I'm trying fuse for first time in my life and I see strange things: 1. no source in mount output, thus it's confusing 2. fuse-zip refers to fusermount, is it needed? 3. some options for fuse bindfs[1] do not work and output is strange 1. # fuse-zip /home/jirib/downloads/webtorrent-0.2.6.zip /mnt # mount -t fuse -v fusefs () on /mnt type fuse (rw, local, ctime=Sat Jun 14 01:53:42 2014) 2. see man fuse-zip... 3. # fuse-zip -d /home/jirib/downloads/webtorrent-0.2.6.zip /mnt fuse: unknown option -d # bindfs -d /home/jirib/tmp /mnt # bindfs --perms=a-w /home/jirib/tmp /mnt fuse: unknown option --perms=a-w # bindfs /home/jirib/tmp /mnt # mount -v -t fuse fusefs () on /mnt type fuse (rw, local, ctime=Sat Jun 14 01:55:41 2014) Huh, is this fuse really ready to use? I'm running this # sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #126: Mon May 12 22:40:04 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP [1] http://bindfs.org/ j.
