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

101–110 of 137 posts

Re: Userspace FUSE for macOS

#101

Post by mdaniel »

sroussey wrote: post #66
mdaniel wrote: post #63

Earlier quoted context omitted.

Yes, I think that's a perfectly reasonable assumption given that (AFAIK) the only current "containerization" (as GP used that word) strategy is on Linux. BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux. I guess put another way: you run Darwin in production? As for the latter, macOS…

Thanks for this. I have a library that uses 1Password files and have not updated for v8.

Be forewarned that (to the best of my knowledge) they haven't, and likely don't intend, to document the sqlite structure. The contents in the sqlite file seems to mirror the api responses from their new rest apis, so their Burp analyzer (https://github.com/1Password/burp-1password-session-analyzer...) may help matters, as will the absolutely essential reading (https://darthnull.org/inside-1password/) along with its code (https://github.com/dschuetz/1password#readme) and I just found this while digging up those other links: https://github.com/mickaelperrin/onepassword-local-search/bl...

Re: Userspace FUSE for macOS

#102

Post by mdaniel »

TimTheTinker wrote: post #61
mdaniel wrote: post #6

Earlier quoted context omitted.

That "repo" appears to exist solely for housing the release artifacts, for those who came to the comments looking for "the goods" Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer"

> Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer" Do you have any specific concerns with the text of the license? The text seems clear enough that there don't appear to be any potential liabilities from using the software in a personal capacity. As I understand it, the worst that could happen is that the license/software author could unknowingly incur liabilities from…

Aside from the great sibling observation, I'll pile onto that by pointing out they seem to have truncated the URL for their LGPL repo citation

IANAL-either but my mental model is that one should not "blaze trails" in making up licenses. I find it does not pass the straight-face test that no other license in the known world captures the author's intentions, so they had to make one up on the fly, typos and all

Re: Userspace FUSE for macOS

#103

Post by lvh »

This is super smart. I've been working on a pet project that requires a VFS, and I ended up with a FUSE impl for Linux (and macOS if so inclined) and a userspace (specifically, JVM) NFSv4 impl :D Really excited to throw out some code.

Re: Userspace FUSE for macOS

#104

Post by EdSchouten »

concerned_ctzn wrote: post #56
EdSchouten wrote: post #52

Earlier quoted context omitted.

> I don't understand the comment about leaking memory, nfs file handles don't have to be persistent. As long as the file the NFSv4 file handle refers to is still usable (i.e., linked into the file system), the NFSv4 file handle must remain usable. Note that this is not a universal requirement, but at least one that the macOS NFSv4 client enforces. It only implements FH4_PERSISTENT. This doesn't seem to be documented…

I'm not sure I understand you point, if an inode gets removed, then GETATTR or LOOKUP would fail as it should unless you're talking about open files. In the latter case the inode will get removed when the last open handle to the file is closed

Sure, LOOKUP would obviously fail, as the object is no longer present in the file system under any name. GETATTR is a different story. Consider this sequence of operations:

    $ mkdir foo
    $ cd foo
    $ rmdir ../foo
    $ stat .                                                                                    
    16777221 401089477 drwxr-xr-x 2 ed staff 0 64 "Sep  6 06:41:05 2022" "Sep  6 06:41:05 2022" "Sep  6 06:41:05 2022" "Sep  6 06:41:05 2022" 4096 0 0 .
Notice how we removed a directory, and were still able to obtain its attributes afterwards using GETATTR. In fact, I can even go ahead and modify some of its attributes using SETATTR:

    $ touch .
    $ stat .
    16777221 401089477 drwxr-xr-x 2 ed staff 0 64 "Sep  6 06:45:34 2022" "Sep  6 06:45:34 2022" "Sep  6 06:45:34 2022" "Sep  6 06:41:05 2022" 4096 0 0 .
So that's what FORGET is for. It allows the kernel to hold on to inodes, even if they have been unlinked from the underlying file system, regardless of whether they are opened or not.

I think it's important to realise that a FUSE nodeid _does not_ represent an identifier of an inode in the file system. Instead, they are identifiers of the inode in the kernel's inode cache. Every time the object is returned by LOOKUP, MKDIR, MKNOD, LINK, SYMLINK or CREATE, should their reference count be increased. FORGET is called to decrease it again.

Re: Userspace FUSE for macOS

#106

Post by EdSchouten »

justsomeadvice0 wrote: post #58
EdSchouten wrote: post #5

What a coincidence! For a project that I maintain (Buildbarn, a distributed build cluster for Bazel) I recently generalized all of the FUSE code I had into a generic VFS that can both be exposed over FUSE and NFSv4. The intent was the same: to provide a better out of the box experience on macOS. Here's a design doc I wrote on that change. Slight warning that it's written with some Buildbarn knowledge in mind. https:/…

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…

For Buildbarn I need to provide a writable file system that acts in a POSIX compliant way. I'm not convinced WebDAV could provide that.

Re: Userspace FUSE for macOS

#107

Post by ianlevesque »

skissane wrote: post #77
rgovostes wrote: post #4

Unfortunately, like macFUSE, this is not really open source. The license appears to be BSD-like for non-commercial use only. Also like macFUSE, the project uses GitHub but the source code is not available. https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt

The developer says they will release source code soon – https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... – although keeping the restrictive license. Apple is introducing user-space file system technology in macOS – LiveFS/UserFS/com.apple.filesystems.lifs – some of the infrastructure turned up in Monterey, in Ventura it is actually being used for mounting FAT/exFAT filesystems. It looks like for now Ap…

They have the right to use whatever licensing they want, but it is strange that this one area - FUSE on Mac - consistently attracts developers using weird license restrictions.

Re: Userspace FUSE for macOS

#108

Post by clhodapp »

mdaniel wrote: post #63
clhodapp wrote: post #22

Earlier quoted context omitted.

You're assuming that everyone's "prod" is a Linux server. I would say that MacOS needs containers for developing Darwin software.

Yes, I think that's a perfectly reasonable assumption given that (AFAIK) the only current "containerization" (as GP used that word) strategy is on Linux. BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux. I guess put another way: you run Darwin in production? As for the latter, macOS…

I guess put another way: you run Darwin in production?

Anyone who builds software for MacOS, iOS, or iPadOS targets Darwin as their production environment. This includes end user applications and tools used by other devs.

Re: Userspace FUSE for macOS

#109

Post by cpuguy83 »

origin_path wrote: post #39
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 added UNIX domain sockets in recent years. They work everywhere now.

Depending on what you need to do. Last I looked things like SCM_RIGHTS.

Re: Userspace FUSE for macOS

#110

Post by cpuguy83 »

searealist wrote: post #99
skissane wrote: post #74

Earlier quoted context omitted.

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.

This can be pretty dangerous because it is basically the same as using a TCP socket on localhost (assuming you are speaking of abstract sockets).
Post reply on HN