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

91–100 of 137 posts

Re: Userspace FUSE for macOS

#91

Post by skissane »

chungy wrote: post #89
skissane wrote: post #88

Earlier quoted context omitted.

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.

Cool. So to update your list:

> Things that support SMB out of the box: Windows, Mac, Linux, FreeBSD, NetBSD, illumos

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

OpenBSD is the only real difference here. (And if "install something from ports" counts as "out of the box", there is no difference.)

There is still somewhat of a difference in ease-of-use though. For NFS, Windows users have to enable an OS feature which is not enabled by default. (I suppose one could automate that in the installer, run a PowerShell script for example.) Not sure how true that is for other platforms.

It still raises the question of why one might prefer NFSv4 vs SMB.

Re: Userspace FUSE for macOS

#92

Post by chrismonsanto »

skissane wrote: post #81
chrismonsanto wrote: post #78

Earlier quoted context omitted.

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.

Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.

Re: Userspace FUSE for macOS

#93

Post by skissane »

chrismonsanto wrote: post #92
skissane wrote: post #81

Earlier quoted context omitted.

> 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.

Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.

I think the answer on Windows is "No".

One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.)

Makes one really wish there was a bindat() call:

  int bindat(int sockfd, const struct sockaddr *addr, socklen_t addrlen, int dirfd);
or maybe funixsockat:

  int funixsockat(int type, int dirfd, const char * name);
which would combine socket() and bind() in a single call

Re: Userspace FUSE for macOS

#94

Post by DannyBee »

chungy wrote: post #89
skissane wrote: post #88

Earlier quoted context omitted.

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.

". It has supported NFSv4 since Windows 8."

Only as a server. https://docs.microsoft.com/en-us/windows-server/storage/nfs/...

It has never supported nfsv4 as a client.

Re: Userspace FUSE for macOS

#95

Post by DannyBee »

keepquestioning wrote: post #87
concerned_ctzn wrote: post #26

Earlier quoted context omitted.

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

Maybe?

Maybe they also shouldn't ship garbage that doesn't work and expect others to debug it?

Maybe this should also happen before you deprecate and make it essentially impossible to install kext's? (It's possible, but trying to walk users through it is a great way to lose 99% of your user base instantly)

(My experience with driverkit is identical to the parent's)

The whole "we removed it for security reasons" is also a hilarious facade.

The linux kernel has a much more expansive (heck, crazy!) driver interface and number of drivers.

Yet, the rate of system compromise due to them vs applications/servers is probably 99 to 1 in favor of applications/servers.

Re: Userspace FUSE for macOS

#96

Post by macintux »

jbverschoor wrote: post #37
pstuart wrote: post #29

Earlier quoted context omitted.

2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.

Api is still socket api.. AF_INET vs AF_UNIX. It takes a few lines of code to have to option to switch between. Ignorance makes sense.. I guess full stack developers means people who can read the top 5 lines of a stack trace

> I guess full stack developers means people who can read the top 5 lines of a stack trace

C'mon. Do I really need to quote the guidelines to you?

Re: Userspace FUSE for macOS

#97

Post by jstarks »

skissane wrote: post #93
chrismonsanto wrote: post #92

Earlier quoted context omitted.

Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.

I think the answer on Windows is "No". One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.) Makes one reall…

In Windows we actually have a way to set the parent directory for a UDS bind or connect, via a socket ioctl. It’s not documented yet, but it’s in the header.

Re: Userspace FUSE for macOS

#98

Post by pabs3 »

searealist wrote: post #42
10000truths wrote: post #41

Earlier quoted context omitted.

That’s plenty for most applications, no? /var/run/*.sock isn’t that many characters.

For many applications it is enough. For others, such as placing a UDS in a user's home directory or temp folder, it may not be. Often times you don't know ahead of time what the path may be.

Unix sockets should definitely not be in any non-tmpfs filesystem, subdirectories of /run are the sole place they should be.

Re: Userspace FUSE for macOS

#99

Post by searealist »

skissane wrote: post #74
searealist wrote: post #32

Earlier quoted context omitted.

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

Is anybody trying to lift that limitation? It seems like an obvious target for kernel devs to tackle. If Linux and *BSD did it (especially if they adopted a mutually compatible implementation), the POSIX standardisation team (Austin Group) would likely be interested in adding it to POSIX, and Windows/macOS/AIX/etc will likely follow their example sooner or later.

Linux has an extension that allows an arbitrary string that is not tied to the filesystem. This makes it easier to stay within the limit or you can crypto hash an arbitrarily long string down to 108 chars.

Re: Userspace FUSE for macOS

#100

Post by searealist »

pabs3 wrote: post #98
searealist wrote: post #42

Earlier quoted context omitted.

For many applications it is enough. For others, such as placing a UDS in a user's home directory or temp folder, it may not be. Often times you don't know ahead of time what the path may be.

Unix sockets should definitely not be in any non-tmpfs filesystem, subdirectories of /run are the sole place they should be.

Care to justify your advice?
Post reply on HN