Are we sure this should be part of DiscUtils?

It might be a good candidate for a seperate project though, f.ex. DiscUtils.Servers.NFS (if it's to be part of DU).

Are we sure this should be part of DiscUtils?

I'm not sure, and don't really have a strong opinion on it 😄. NFS and iSCSI are two 'network-based' file systems which are part of DiscUtils and I guess you can argue whether they should be in scope at all.

I'm fine with splitting the server part off to a separate project.
On the other hand, it's just two/three source files, so not sure whether it's really worth the effort.

If we do move to a separate library, some additional classes inside DiscUtils.Nfs would need to be made public.

I'm going to keep pushing to this branch for now as I complete the server work; let's continue the discussion.

Ok - so the API stuff, like protocol messages and potentially even a client, without a doubt should go into the NFS package. An actual server is another thing entirely .. I would still think it needs to go in another package, like DiscUtils.NFS.Server (and at that point, it should be something you instantiate in a consuming program, with options n stuff).

As for public classes. In some cases they should be public (else others wouldn't be able to make their own NFS servers), while others probably can go by with being shared in an InternalsVisibleTo-style thing.

I did some more work on the NFS server implementation:

• Reworked the code a bit, and moved the NFS server-related code to a separate DiscUtils.Nfs.Server library. That should help keep things separated.
• Updated the NfsFileServer class so that instead of serving from a directory on the local operating system, it can serve files from any class that implements IFileSystem. So if you wanted to, you could now setup a NFS server which serves the contents of a IMG, VHDX or ISO file using DiscUtils.
• Better support for weak cache consistency.

As to testing, I used the NfsServer utility to share a folder on my Windows machine and access it from a Linux VM.

Some of the operations I tested are:

• Mounting the file share
• Listing contents of a folder
• Creating a new file with touch/nano/echo
• Modifying a file
• Renaming a file with mv
• Deleting a file with rm

I tested with both the Facebook nfusr library as well as normal Linux mount. (nfusr has more verbose debug output, doesn't required sudo permissions and is easier to restart).

Long story short, things starting to look good 😄 .

Great :)

What's lacking?