适用于macOS（以及未来的GNU/Linux）的.NETStandard中的FUSE包装器-C#-C-下载

# FuseSharp FuseSharp is a **FUSE** wrapper for **macOS** (GNU/Linux in the future) developed in C# by Códice Software. It provides a clean API designed specifically to enable the development of userspace filesystems in .NET applications. FuseSharp only uses .NET Standard 2.0 features, so it is highly interoperable with other .NET Platforms such as Core, Mono, and Xamarin.Mac. * [Goal](#goal) * [Usage scenarios](#usage-scenarios) * [Setup and usage](#setup-and-usage) * [Project Overview](#project-overview) * [Performance tests](#performance-tests) * [License](#license) ## Goal The goal of this project is to provide an API which enables C# applications to easily implement a filesystem in user-space. This API is written in C# and solely relies on **.NET Standard 2.0 features**, so it's compatible with the following .NET platforms: | Platform | Minimum version | |---------------:|----------------:| | .NET Core | 2.0 | | .NET Framework | 4.6.1 | | Mono | 5.4 | | Xamarin.Mac | 3.8 | ### Usage scenarios If you stumbled upon this repository by accident, you might be wondering _"why would I want / need to build a filesystem in user space?"_ The answer is: a filesystem adds a layer of abstraction that empowers and eases use cases you might not have thought of before. And because said FS is running on user space, you can let FUSE do the heavy lifting, while you will only need to focus on what really matters development-wise. Did you know there is a filesystem that lets you watch YouTube videos as if they were locally stored in you machine, without having to navigate to the web portal? Or that you can add a transparent encryption layer to a directory tree, to let your users have a secure storage without having to deal with how files are encrypted and decrypted? Here are some other FUSE-powered filesystem implementations in the wild that might inspire you (mind that **none** of them were developed using FuseSharp, let us know if you implement one yourself with this library!): * [**SSHFS**](https://github.com/osxfuse/osxfuse/wiki/SSHFS): Mounts a remote directory tree through a SSH connection. * [**EXT**](https://github.com/osxfuse/osxfuse/wiki/Ext): Provides [EXT filesystem](https://en.wikipedia.org/wiki/Extended_file_system) support for macOS (read by default, but write can be enabled). * [**NTFS-3G**](https://github.com/osxfuse/osxfuse/wiki/NTFS-3G): Provides [NTFS filesystem](https://en.wikipedia.org/wiki/NTFS) support for macOS (both read and write). * [**XFS**](https://github.com/osxfuse/osxfuse/wiki/XFS): Provides [XFS filesystem](https://en.wikipedia.org/wiki/XFS) support for macOS. * [**procfs**](https://github.com/osxfuse/osxfuse/wiki/procfs): Implements a [procfs filesystem](https://en.wikipedia.org/wiki/Procfs) on macOS, which [is not provided by default](http://osxbook.com/book/bonus/chapter11/procfs/). * [**Accessibility FS**](https://code.google.com/archive/p/macfuse/wikis/MACFUSE_FS_ACCESSIBILITYFS.wiki): A filesystem that exposes the applications that are running in your computer, and the user interface elements said applications expose (including the properties of this GUI components!). * [**YouTube FS**](https://code.google.com/archive/p/youtubefs/): YoutubeFS enables you to browse your favorite Youtube videos locally on your desktop without going to the youtube website. * [**fuse-zip**](https://bitbucket.org/agalanin/fuse-zip): Implements a filesystem to navigate, extract, create and modify ZIP and ZIP64 archives based on libzip implemented in C++, working with ZIP archives as real directories. ## Setup and usage The project is **not** available in NuGet for now. In order to start using it, you must follow these steps: 1. Clone this repository. 2. Install dependencies: * ``glib`` 2.56.1. It is available for macOS users through ``brew``. * .NET Core SDK. * Apple Developer Tools. 3. Compile and install the adaptor library: * Executing the `buildandcopy` script located at `/src/Adaptor` 4. Compile the FuseSharp library and the example application: * Executing `dotnet build` at `/src/FuseSharp`, or opening the FuseSharp solution with your IDE of choice and building it. Once you complete these steps, you can add your `FuseSharp.dll` assembly as a project dependency. If you distribute an application that uses FuseSharp, bear in mind that, in order to run the application, **the target machine needs to have installed the ``Adaptor.dylib`` library** compiled at step 3. ### Example application You can also browse and play with the example application located at `src/FuseSharp/example`. The application is self-explanatory if executed without arguments. It implements two different User-Space Filesystems: * Mirror: it creates a mirror FS, mounted at the specified path, mirroring the content of the root path specified. * Encrypted: it creates an encrypted FS, mounted at the specified path, mirroring and encrypting/decrypting the content of the root path specified on the fly. To implement your own filesystem, you need to subclass the ``FileSystem`` type, overriding the necessary methods. You can browse the example to see how. Here's a little GIF demonstrating how it works:  Once you have finished your filesystem, mounting it is as easy as this: ``` using (MyOwnFileSystemImpl fs = new MyOwnFileSystemImpl(targetRoot)) using (FileSystemHandler fsh = new FileSystemHandler(fs, args)) { int result = fsh.start(); } ``` ### FileSystemHandler arguments The arguments used to instantiate a `FileSystemHandler` instance are, in the end, passed down to FUSE. FUSE's arguments documentation is sometimes hard to find, but we have collected and tested the following (apart from the [usual args](https://github.com/osxfuse/osxfuse/wiki/Mount-options)): | Option | Description | Source | |--------|-------------|--------| | ``big_writes`` | FUSE driver option - enabled max_write | [Question about write buffer size](http://fuse.996288.n3.nabble.com/Question-about-write-buffer-size-td13137.html) | | ``max_write`` | Libfuse option. Max write size in bytes | [Question about write buffer size](http://fuse.996288.n3.nabble.com/Question-about-write-buffer-size-td13137.html) and [To FUSE or not to FUSE](https://www.usenix.org/system/files/conference/fast17/fast17-vangoor.pdf) | | ``writeback_cache`` | Libfuse option | [Question about write buffer size](http://fuse.996288.n3.nabble.com/Question-about-write-buffer-size-td13137.html) and [To FUSE or not to FUSE](https://www.usenix.org/system/files/conference/fast17/fast17-vangoor.pdf) | | ``splice_read``, ``splice_write``, ``splice_move`` | Activate splicing for all operations | [To FUSE or not to FUSE](https://www.usenix.org/system/files/conference/fast17/fast17-vangoor.pdf) | | ``direct_io`` | Some file systems may not know the sizes of files that they provide. This could be because a file's content is being streamed so it's difficult or impossible to know the "size" of the file. The content could be dynamically changing so it may not make sense to advertise a size at getattr time only to find that the size has changed at read or write time. procfs is a good example of a osxfuse file system with such needs. What these file systems would like is to be able to allow reads and writes without the file size mattering. This isn't normally possible in the normal I/O paths in the kernel. In particular, short reads from a user-space file system will be zero filled by osxfuse. The ``direct_io`` option causes osxfuse to use an alternative "direct" I/O path between the kernel and the user-space file system. This path makes the file size irrelevant--a read will go on until the file system keeps returning data. There is