563f47c299
|
||
|---|---|---|
| fsutil | ||
| fuseops | ||
| fusetesting | ||
| fuseutil | ||
| internal | ||
| samples | ||
| .gitignore | ||
| .travis.yml | ||
| LICENSE | ||
| README.md | ||
| connection.go | ||
| doc.go | ||
| errors.go | ||
| mount_config.go | ||
| mount_darwin.go | ||
| mount_linux.go | ||
| mounted_file_system.go | ||
| unmount.go | ||
| unmount_linux.go | ||
| unmount_std.go | ||
README.md
This package allows for writing and mounting user-space file systems from Go. It is a wrapper around bazil.org/fuse, which does the heavy lifting. It does not make use of the bazil.org/fuse/fs sub-package, which allows for something like an object-orientend representation of files and directories, and contains a decent amount of canned behavior.
The chief improvements and/or differences from the bazil.org packages are:
-
No surprises in the form of magic/default behaviors. You must provide an implementation for every method in the interface. Embed a
fuseutil.NotImplementedFileSystemstruct to have default implementations that returnENOSYS. -
Every method, struct, and field is thoroughly documented. This may help you get your bearings in the world of FUSE, the Linux VFS, traditional file system implementations, etc., all of which tend to be very poorly documented.
-
Support for arbitrary offsets in directory entries returned by
ReadDir. (The bazil.org package assumes that offsets must be counts of bytes.)
The very large disadvantage over using the bazil.org packages is that many features have not yet been exposed.
Make sure to see the sub-packages of the samples package.