Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Userspace FUSE for macOS

fuse-t.org

Post reply on HN
Print view View original

81–90 of 137 posts

Re: Userspace FUSE for macOS

#81

Post by skissane »

chrismonsanto wrote: post #78
searealist wrote: post #32

Earlier quoted context omitted.

Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.

This limitation only applies to the file name, as you can chdir to the directory before bind/connect. Unfortunate but not a deal breaker

> you can chdir to the directory before bind/connect

Since working directory is per-process not per-thread, this seems a great way to introduce race condition bugs. It also basically rules it out for anything meant to be used as a library or framework.

Re: Userspace FUSE for macOS

#82

Post by [deleted] »

skissane wrote: post #76
justsomeadvice0 wrote: post #58

Earlier quoted context omitted.

You might look at webdav instead, which has actual existing library implementations (unlike NFSv4), supports user/pass auth (in some cases you don't want wide-open services on loopback) and is based on HTTP; that would make the whole thing easier. Various projects offer a webdav combat layer, see cryptomator for one example: https://docs.cryptomator.org/en/latest/desktop/vault-mountin... I went down the NFS road long…

I remember, around 10 years ago, mucking around with WebDAV, and discovering many WebDAV clients were extremely crapulent. Especially on Windows. Maybe, some years later, Windows' WebDAV client has improved. And I can't remember whether macOS WebDAV was better or not.

[deleted]

Re: Userspace FUSE for macOS

#83

Post by realloc »

I built something similar for a personal project (though not using the FUSE API) with Samba running locally. Samba has a VFS API which isn’t terrible complicated and lets you accomplish mostly the same thing: https://wiki.samba.org/index.php/Writing_a_Samba_VFS_Module

The only problem I ran into was not being able to bind to 127.0.0.1:445, or connect to a different port, on Windows. I ended up writing a small pcap program that would look for packets going out to some other ip and replay them back at localhost on the port samba was running on, so Windows thought it was connecting to a remote machine. It was a ridiculous solution and I’m sure there’s a better way, but it worked for what I needed.

Re: Userspace FUSE for macOS

#86

Post by chungy »

skissane wrote: post #75

What advantages does NFSv4 have over SMB/CIFS for this use case? I have had the same idea myself before, but with a more cross-platform scope (Linux and Windows too, not just macOS). Whatever it flaws, SMB/CIFS has the advantage of being supported out-of-the-box on more platforms than NFSv4 is.

Are you sure about that?

Things that support SMB out of the box: Windows, Mac

Things that support NFSv4 out of the box: Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, illumos

Re: Userspace FUSE for macOS

#87

Post by keepquestioning »

concerned_ctzn wrote: post #26
keepquestioning wrote: post #7

Earlier quoted context omitted.

Could this be done using DriverKit

The author here. DriverKit is really a no-go. A while back I was asked to do a project based on DriverKit, it took me nowhere because of countless bugs and semi-implemented features, worse yet, it caused system crashes (and it was supposed to be stable).

You should send feedback

Re: Userspace FUSE for macOS

#88

Post by skissane »

chungy wrote: post #86
skissane wrote: post #75

What advantages does NFSv4 have over SMB/CIFS for this use case? I have had the same idea myself before, but with a more cross-platform scope (Linux and Windows too, not just macOS). Whatever it flaws, SMB/CIFS has the advantage of being supported out-of-the-box on more platforms than NFSv4 is.

Are you sure about that? Things that support SMB out of the box: Windows, Mac Things that support NFSv4 out of the box: Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, illumos

The Linux kernel contains both NFS and SMB clients – so in that sense, supports both equally "out of the box". Whether either or both are compiled-in (or available as loadable modules) will depend on the distribution.

Windows has an NFS client, but it is an additional OS feature which isn't installed by default (and I believe its NFS version support is somewhat outdated?)

Whether Linux distributions install the NFS and/or SMB client support by default, or require an additional package install for either or both, is really going to depend on the distribution (and its installation options)

FreeBSD, NetBSD and Illumos also include SMB client support, but I don't know how easy it is to use them as compared to their NFS clients. (From what I understand, OpenBSD pointedly has first-class support for NFS but not SMB: NFS has an in-kernel client, for SMB you have to use a user-space NFS-to-SMB translation daemon, which is in their ports tree.)

Re: Userspace FUSE for macOS

#89

Post by chungy »

skissane wrote: post #88
chungy wrote: post #86

Earlier quoted context omitted.

Are you sure about that? Things that support SMB out of the box: Windows, Mac Things that support NFSv4 out of the box: Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, illumos

The Linux kernel contains both NFS and SMB clients – so in that sense, supports both equally "out of the box". Whether either or both are compiled-in (or available as loadable modules) will depend on the distribution. Windows has an NFS client, but it is an additional OS feature which isn't installed by default (and I believe its NFS version support is somewhat outdated?) Whether Linux distributions install the NFS a…

> Windows has an NFS client, but it is an additional OS feature which isn't installed by default (and I believe its NFS version support is somewhat outdated?)

Windows has both NFS server and client. It's not enabled by default, but it can be enabled. It has supported NFSv4 since Windows 8.

Re: Userspace FUSE for macOS

#90

Post by nu11ptr »

10000truths wrote: post #36
inetknght wrote: post #30

Earlier quoted context omitted.

> Why does everybody use tcp ports instead of file sockets for local communication? In my experience it's because Windows and mac developers aren't aware of local file sockets. Windows API, in particular, doesn't have a similar concept if I recall.

Windows 10 has support for UNIX sockets.

Wow, interesting - I didn't know that. That is very cool... no more special handling for windows in cross platform handling then it sounds like (at least for UDS).
Post reply on HN