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

81–90 of 105 posts

Re: The File Filesystem (2021)

#81

Post by russfink »

lambdaxyzw wrote: post #77
jraph wrote: post #25

Earlier quoted context omitted.

It exists :-) For zip archives, there are fuse-zip and mount-zip which are FUSE filesystem. As an intermediate between OS level and application-level, there are desktop environment level: gvfs for GNOME and KIO for KDE, but they are compatible only in their own ecosystems.

Would be nice to have something that integrates with 7z - it supports a lot of weird archive types, including "weird" ones I care about (for example PE files, better known as ".exe files").

Or zstd. I have some dd blobs of partitions, the blobs are zstandard-compressed, would like to mount them.

Re: The File Filesystem (2021)

#82

Post by irusensei »

yjftsjthsd-h wrote: post #4

I would gently suggest naming it filefs or something; ffs already means https://man.freebsd.org/cgi/man.cgi?ffs(7) That said - good idea/approach; seems like an excellent way to cleanly extend the unix approach to structured file formats:)

Yeah please rename it to JFS (JSON File System). Oh wait...

Re: The File Filesystem (2021)

#83

Post by xk3 »

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.

> Compressed archives, for one

You can look inside of archives pretty easily with `lsar` (part of the unar package). It works with disk images like ISO 9660 files too

But yes, especially for nested archives, having deeper OS support would be nice.

Re: The File Filesystem (2021)

#85

Post by crabbone »

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.

I thought archivemount already did that. Am I missing something?

Anyway, even if that's not what you are looking for, FUSE is a more general mechanism that will allow you to do what you want (well, it seems like, at least) and much more.

Re: The File Filesystem (2021)

#86

Post by crabbone »

frizlab wrote: post #24
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.

Honest question: How is this useful? I don’t see any use-case where this would come in handy.

We used this in Gitlab CI. Unfortunately, the only way they deal with artifacts is by putting them in Zip files. Cache between builds would thus be stored as a Zip file. However, fully extracting it before each build would sometimes take as much, if not more time than to just build fresh. Mounting a Zip file as a filesystem allows extracting entries on-demand, at the time a file access would've been made. This was a notable speedup in our compilation process.

Re: The File Filesystem (2021)

#87

Post by fishyjoe »

PMunch wrote: post #71

Oh this is cool! I recently wrapped libfuse in Nim and after porting the 'hello' filesystem example I made one which is more or less exactly this. However my version you pipe data and have to provide a mountpoint, then when it's done it writes the result over stdout. That means you can inline it in a pipe chain but also that you have to make sure to grab the output. At the moment I'm exploring other stuff which could…

Would you mind sharing the Nim code? I've been interested in working with FUSE for a while, and use Nim for a few projects.

No worries if not, I'm just curious!

Re: The File Filesystem (2021)

#88

Post by skissane »

skissane wrote: post #65
ranger_danger wrote: post #63

Earlier quoted context omitted.

What about the File Provider API?

It is designed for the cloud storage use case (Dropbox, Google Drive, etc) - it creates local copies of files and synchs them with remote ones. Not what you want to do in the general case.

I take it from the downvotes people think what I said is factually wrong?

If that's the case, I wish someone would point out where I've got it wrong instead of just silently downvoting

Re: The File Filesystem (2021)

#89

Post by yjftsjthsd-h »

irusensei wrote: post #82
yjftsjthsd-h wrote: post #4

I would gently suggest naming it filefs or something; ffs already means https://man.freebsd.org/cgi/man.cgi?ffs(7) That said - good idea/approach; seems like an excellent way to cleanly extend the unix approach to structured file formats:)

Yeah please rename it to JFS (JSON File System). Oh wait...

There is a reason I suggested "filefs"; 3 chars isn't really enough to easily be unambiguous.

Re: The File Filesystem (2021)

#90

Post by samatman »

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…

I've been using OSX since 2003, and developing on it for more than ten years. At no point have I seen anything that it's reasonable to call "tightening macOS", let alone the absurd claim of complete control except for an inner circle of elite companies.

The closest thing would be adding the attestation system, so that unsigned binaries have to be explicitly given permission to run... once. That's a security feature which trades a bit of convenience for a lot of protection, especially for the average user. I have no problem with that sort of thing.

I see this sort of sentiment very frequently from non-users of the operating system, but never from those of us who actually use it. Go figure.

Post reply on HN