[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag stable_URL]]

`libfuse` is an Hurd-specific implementation of [FUSE](http://fuse.sourceforge.net),
initially written by Stefan Siegl.

The implementation takes advantage of the [[translators|translator]] facilities
of Hurd: this means that applications that implement a FUSE filesystem, when
compiled against libfuse-hurd, become translators to be set with usual [[settrans]]
etc.


# Status

* Only part of the API is implemented
    * lowlevel API not implemented
    * Options handling (`fuse_parse_cmdline` and `fuse_opt_*`) not implemented
    * CUSE lowlevel not supported (compatibility level 29)
* Supports the compatibility level 25 and 26, up to libfuse 2.6.x
* File I/O is quite slow.


## IRC, freenode, #hurd, 2013-05-31

    <zacts> well the reason I'm asking, is I'm wonder about the eventual
      possibility of zfs on hurd
    <pinotree> no, zfs surely not
    <zacts> *wondering
    <zacts> pinotree: would that be because of license incompatabilities, or
      technical reasons?
    <pinotree> the latter
    <taylanub> It's just a matter of someone sitting down and implementing it
      though, not ?
    <pinotree> possibly
    <braunr> zacts: the main problem seems to be the interactions between the
      fuse file system and virtual memory (including caching)
    <braunr> something the hurd doesn't excel at
    <braunr> it *may* be possible to find existing userspace implementations
      that don't use the system cache (e.g. implement their own)
    <braunr> and they could almost readily use our libfuse version


## IRC, freenode, #hurd, 2013-10-01

    <pinotree> our libfuse implementation is still basic atm (there's a wiki
      page about it)
    <alsuren> okay... talk to me about FUSE
    <pinotree> even with the improvements i have in my public branch, it still
      cannot do real-world fs'es
    <alsuren> okay, so you're the person to ask about FUSE
    <alsuren> it strikes me that HURD not having FUSE support is a bit of an
      architectural oversight
    <pinotree> i'm not sure what's your point about fuse, since what fuse on
      linux (and not only) does is done *natively* by the hurd
    <alsuren> exactly
    <pinotree> all of the hurd filesystems (which are just a type of servers)
      run in userspace already
    <alsuren> so FUSE should Just Work
    <pinotree> well no


# Source

[[source_repositories/incubator]], libfuse/master.