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

The File Filesystem (2021)

mgree.github.io

Post reply on HN
Print view View original

51–60 of 105 posts

Re: The File Filesystem (2021)

#51

Post by skissane »

lmm wrote: post #44
RetroTechie wrote: post #21

Useful enough that it should be an OS-level standard feature, imho. Unix-like OSes allow mounting disk images to explore their contents. But there's many more file formats where exploring files-inside-files is useful. Compressed archives, for one. Some file managers support those, but (imho) application-level is not the optimal layer to put this functionality. Could be implemented with a kind of driver-per-filetype.

This was a core design feature of reiserfsv4, but Linux ultimately refused to merge it, probably not helped by the whole murdering-his-wife thing.

> This was a core design feature of reiserfsv4, but Linux ultimately refused to merge it

IIRC, because it contained these strange beasts which functioned as both files and directories - i.e. cat would return data, but then you could cd into them and run ls. Linus (among others) didn’t want to permit those violations of the file-directory dichotomy into the Linux kernel.

Re: The File Filesystem (2021)

#53

Post by generalizations »

metadat wrote: post #34
khc wrote: post #30

Earlier quoted context omitted.

does it have to be fuse? cant you mount a disk image with loopback

But will the disk image be fully stored in memory? No.. not with loopback. Either that, or it won't be mutable in memory with commit on unmount.

Put the disk image inside a ramdisk and it's in memory. Write a script for saving to physical disk when dismounting, and you're done.

Re: The File Filesystem (2021)

#54

Post by bombcar »

salgernon wrote: post #23
vidarh wrote: post #15

Earlier quoted context omitted.

Daniel Stenberg, of cURL fame, co-write an Amiga-editor called FrexxEd where the open buffers were exposed as files in the filesystem. Meaning you could write any shell script to manipulate an open buffer (not that important as it also exposed all editor functionality both via IPC via Arexx and via FPL - a C-like scripting language), and that you could e.g. compile without saving ( that was very helpful on a system w…

Classic MacOS in the 80s had "MPW" macintosh programmers workshop - that treated open text windows as files and selections within the windows as files , so it wasn't uncommon to have a portion of an otherwise documentation file have a "click here and hit enter", which would use the selected text as stdin for some semi-ported unix tool. (no memory protection or multitasking, so true pipelines with backpressure didn't…

BBEdit has something akin - you can select text and run a Unix command on the selection via temp files. Very useful

Re: The File Filesystem (2021)

#55

Post by nine_k »

skissane wrote: post #50
duped wrote: post #41

Earlier quoted context omitted.

Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn't provide an API for this natively.

> fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understan…

> why don't they

It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces.

Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a specialist OS completely controlled by Apple, with a few companies like Adobe and Ableton licensing access to its internals.

Re: The File Filesystem (2021)

#56

Post by skissane »

nine_k wrote: post #55
skissane wrote: post #50

Earlier quoted context omitted.

> fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understan…

> why don't they It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces. Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a spe…

Apple used to be a lot more developer-friendly company. It is part of what got them where they are now - the fact that so many developers use Macs, which in turn encourages business software vendors to support Macs

Stuff like this is of little interest to ordinary users (at least not directly), but appeals to developers

By de-emphasising the developer is experience, they are undermining one of the factors that got them to where they are today

Re: The File Filesystem (2021)

#57

Post by ranger_danger »

skissane wrote: post #33
Groxx wrote: post #29

Earlier quoted context omitted.

Does https://osxfuse.github.io/ cover this? Or is there some fundamental issue? (beyond "it's not built in")

Recent macOS versions do have a general purpose built-in API for user mode filesystems. That API is incompatible with FUSE. The big problem is it is undocumented and you need an entitlement from Apple to use it, and Apple won’t give you that. Apple do have a publicly available API for cloud file systems (Dropbox-style products), but it makes a lot of assumptions which makes it effectively unusable for other use cases…

According to the MacFUSE author, their specific approach is not actually undocumented:

> Apple has put it in an umbrella called "unsupported" (in the kernel interfaces section) ... either Apple will not take this interface away, and if they do, it will be to provide a better interface

http://preserve.mactech.com/articles/mactech/Vol.23/23.03/Ma...

Re: The File Filesystem (2021)

#58

Post by arjvik »

throwway120385 wrote: post #48
codetrotter wrote: post #46

Earlier quoted context omitted.

> /tmp isn't stored in memory It is if your system uses tmpfs for /tmp https://en.wikipedia.org/wiki/Tmpfs

The point they were trying to make is that it doesn't have to be, and it isn't in several of the Linux systems I've used over the years. Assuming that it is is a bad idea.

/dev/shm always is though

Re: The File Filesystem (2021)

#59

Post by fsckboy »

vidarh wrote: post #15
isoprophlex wrote: post #2

For fuck's sake! Not everything needs to be a file! (This is a joke. I love the idea and execution.)

Daniel Stenberg, of cURL fame, co-write an Amiga-editor called FrexxEd where the open buffers were exposed as files in the filesystem. Meaning you could write any shell script to manipulate an open buffer (not that important as it also exposed all editor functionality both via IPC via Arexx and via FPL - a C-like scripting language), and that you could e.g. compile without saving ( that was very helpful on a system w…

I want a webbrowser that does that, lets me shell-cd into each tab as a directory

Re: The File Filesystem (2021)

#60

Post by duped »

skissane wrote: post #50
duped wrote: post #41

Earlier quoted context omitted.

Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn't provide an API for this natively.

> fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understan…

> The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it.

If no one can call it it's not an API, it's an implementation detail. And I don't even think its exposed by headers, just alluded to by people who claim APFS is implemented in user space.

> I was wondering what issues you were talking about, and then I found this

Worse than this, it's possible to DoS a Mac with an NFS server just by refusing to reply to a request. That's unacceptable for a user space file system (although FUSE is only kinda better, in that it can force processes that read from the FS into uninterruptable sleep that prevents them from being killed).

> Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?

Because Apple doesn't give a fuck about developers. Every developer will eventually learn this, but for those that haven't - Apple doesn't want you writing software for their platform, unless you're an Apple employee and on an Apple team paid to do it. It's why their docs suck, it's why to learn anything you need to watch ADC videos instead of read manpages, and it's why all the cool stuff is behind protected entitlements that you can't get or will be limited in using.

Post reply on HN