[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6485":3},{"id":4,"name":5,"fullName":6,"owner":5,"repo":5,"description":7,"homepage":8,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":9,"pushedAt":9,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":15,"starSnapshotCount":15,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},6485,"libfuse","libfuse\u002Flibfuse","The reference implementation of the Linux FUSE (Filesystem in Userspace) interface","",null,"C",6067,1276,152,50,0,1,8,33,6,40.32,"Other",false,"master",true,[],"2026-06-12 02:01:25","libfuse\n=======\n\nAbout\n-----\n\nFUSE (Filesystem in Userspace) is an interface for userspace programs\nto export a filesystem to the Linux kernel. The FUSE project consists\nof two components: the *fuse* kernel module (maintained in the regular\nkernel repositories) and the *libfuse* userspace library (maintained\nin this repository). libfuse provides the reference implementation\nfor communicating with the FUSE kernel module.\n\nA FUSE file system is typically implemented as a standalone\napplication that links with libfuse. libfuse provides functions to\nmount the file system, unmount it, read requests from the kernel, and\nsend responses back. libfuse offers two APIs: a \"high-level\",\nsynchronous API, and a \"low-level\" asynchronous API. In both cases,\nincoming requests from the kernel are passed to the main program using\ncallbacks. When using the high-level API, the callbacks may work with\nfile names and paths instead of inodes, and processing of a request\nfinishes when the callback function returns. When using the low-level\nAPI, the callbacks must work with inodes and responses must be sent\nexplicitly using a separate set of API functions.\n\n\nDevelopment Status\n------------------\n\nlibfuse is shipped by all major Linux distributions and has been in\nproduction use across a wide range of systems for many years. However,\nat present libfuse does not have any active, regular contributors. The\ncurrent maintainer continues to apply pull requests and makes regular\nreleases, but unfortunately has no capacity to do any development\nbeyond addressing high-impact issues. When reporting bugs, please\nunderstand that unless you are including a pull request or are\nreporting a critical issue, you will probably not get a response. If\nyou are using libfuse, please consider contributing to the project.\n\n\nSupported Platforms\n-------------------\n\n* Linux (fully)\n* BSD (mostly\u002Fbest-effort)\n* For macOS, please use [macFUSE](https:\u002F\u002Fmacfuse.github.io)\n  \n\nInstallation\n------------\n\nYou can download libfuse from https:\u002F\u002Fgithub.com\u002Flibfuse\u002Flibfuse\u002Freleases. To build and\ninstall, you must use [Meson](http:\u002F\u002Fmesonbuild.com\u002F) and\n[Ninja](https:\u002F\u002Fninja-build.org).  After downloading the tarball and `.sig` file, verify\nit using [signify](https:\u002F\u002Fwww.openbsd.org\u002Fpapers\u002Fbsdcan-signify.html):\n\n    signify -V -m fuse-X.Y.Z.tar.gz -p fuse-X.Y.pub\n    \nThe `fuse-X.Y.pub` file contains the signing key and needs to be obtained from a\ntrustworthy source. Each libfuse release contains the signing key for the release after it\nin the `signify` directory, so you only need to manually acquire this file once when you\ninstall libfuse for the first time.\n\nAfter you have validated the tarball, extract it, create a (temporary) build directory and\nrun Meson:\n\n    $ tar xzf fuse-X.Y.Z.tar.gz; cd fuse-X.Y.Z\n    $ mkdir build; cd build\n    $ meson setup ..\n\nNormally, the default build options will work fine. If you\nnevertheless want to adjust them, you can do so with the\n*meson configure* command:\n\n    $ meson configure # list options\n    $ meson configure -D disable-mtab=true # set an option\n\n    $ # ensure all meson options are applied to the final build system\n    $ meson setup --reconfigure ..\u002F\n\nTo build, test, and install libfuse, you then use Ninja:\n\n    $ ninja\n    $ sudo python3 -m pytest test\u002F\n    $ sudo ninja install\n\nRunning the tests requires the [py.test](http:\u002F\u002Fwww.pytest.org\u002F)\nPython module. Instead of running the tests as root, the majority of\ntests can also be run as a regular user if *util\u002Ffusermount3* is made\nsetuid root first:\n\n    $ sudo chown root:root util\u002Ffusermount3\n    $ sudo chmod 4755 util\u002Ffusermount3\n    $ python3 -m pytest test\u002F\n\nSecurity implications\n---------------------\n\nThe *fusermount3* program is installed setuid root. This is done to\nallow normal users to mount their own filesystem implementations.\n\nTo limit the harm that malicious users can do this way, *fusermount3*\nenforces the following limitations:\n\n  - The user can only mount on a mountpoint for which they have write\n    permission\n\n  - The mountpoint must not be a sticky directory which isn't owned by\n    the user (like \u002Ftmp usually is)\n\n  - No other user (including root) can access the contents of the\n    mounted filesystem (though this can be relaxed by allowing the use\n    of the *allow_other* and *allow_root* mount options in\n    *\u002Fetc\u002Ffuse.conf*)\n\n\nIf you intend to use the *allow_other* mount options, be aware that\nFUSE has an unresolved [security\nbug](https:\u002F\u002Fgithub.com\u002Flibfuse\u002Flibfuse\u002Fissues\u002F15): if the\n*default_permissions* mount option is not used, the results of the\nfirst permission check performed by the file system for a directory\nentry will be re-used for subsequent accesses as long as the inode of\nthe accessed entry is present in the kernel cache - even if the\npermissions have since changed, and even if the subsequent access is\nmade by a different user. This is of little concern if the filesystem\nis accessible only to the mounting user (which has full access to the\nfilesystem anyway), but becomes a security issue when other users are\nallowed to access the filesystem (since they can exploit this to\nperform operations on the filesystem that they do not actually have\npermissions for).\n\nThis bug needs to be fixed in the Linux kernel and has been known\nsince 2006 but unfortunately no fix has been applied yet. If you\ndepend on correct permission handling for FUSE file systems, the only\nworkaround is to use `default_permissions` (which does not currently\nsupport ACLs), or to completely disable caching of directory entry\nattributes.\n\nBuilding your own filesystem\n------------------------------\n\nFUSE comes with several example file systems in the `example`\ndirectory. For example, the *passthrough* examples mirror the contents\nof the root directory under the mountpoint. Start from there and adapt\nthe code!\n\nThe documentation of the API functions and necessary callbacks is\nmostly contained in the files `include\u002Ffuse.h` (for the high-level\nAPI) and `include\u002Ffuse_lowlevel.h` (for the low-level API). An\nautogenerated html version of the API is available in the `doc\u002Fhtml`\ndirectory and at http:\u002F\u002Flibfuse.github.io\u002Fdoxygen.\n\n\nGetting Help\n------------\n\nIf you need help, please ask on the \u003Cfuse-devel@lists.sourceforge.net>\nmailing list (subscribe at\nhttps:\u002F\u002Flists.sourceforge.net\u002Flists\u002Flistinfo\u002Ffuse-devel).\n\nPlease report any bugs on the GitHub issue tracker at\nhttps:\u002F\u002Fgithub.com\u002Flibfuse\u002Flibfuse\u002Fissues.\n","libfuse是Linux FUSE（用户空间文件系统）接口的参考实现，允许用户空间程序向Linux内核导出文件系统。其核心功能包括通过高阶同步API或低阶异步API与FUSE内核模块通信，处理来自内核的请求并返回响应。高阶API简化了文件名和路径的操作，而低阶API则需要直接处理inode，并显式发送响应。libfuse适用于需要在用户空间实现自定义文件系统的场景，如网络文件系统、加密文件系统等。广泛应用于各大Linux发行版中，但目前维护者仅能处理关键问题，鼓励社区贡献代码以支持项目发展。",2,"2026-06-11 03:07:13","top_language"]