What happens if your JSON key has a slash?
The File Filesystem (2021)
91–100 of 105 posts
Re: The File Filesystem (2021)
#92Useful 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.
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.
ratarmount for tar files.
Re: The File Filesystem (2021)
#93Earlier 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…
> it makes a lot of assumptions which makes it effectively unusable for other use cases
What use-cases are foreclosed and why?
Re: The File Filesystem (2021)
#94Useful 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.
It reduces the code required to convert from N-producers to M-consumer from N x M to N+M because they're reading from and to a well-understood common form.
Re: The File Filesystem (2021)
#95Oh 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…
Here's an idea: recursively mount code files/projects. Use something like tree-sitter to extract class and function definitions and make each into a "file" within the directory representing the actual file. Need to get an idea for how a codebase is structured? Just `tree` it :)
Getting deeper into the rabbit hole, maybe imports could be resolved into symlinks and such. Plenty of interesting possibilities!
Re: The File Filesystem (2021)
#96It's an interesting idea but I think the usefulness would be greatly enhanced if it could handle json arrays; most needed json structures contain array elements in my experience
per an issue ticket[1], it can:
setfattr -n user.type -v list # use xattr on macOS
Re: The File Filesystem (2021)
#97Oh 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!
Not PMunch, but bindings¹ and statusbar².
Nimble has a couple of fuse projects and wrappers registered too.
Re: The File Filesystem (2021)
#98this is cool but it's fuse.. which is not so cool.
these days i reach for jq.. I've recently became interested in duckdb too.
Using a tool that is specialized for the format is usually more ideal than a generic one treating everything as files.
There is a lot in JSON that can't be represented in a flexible way as files and directories. For instance, what if a key has "/" in it.. What happens to lists and their order when you re-serialize How are hashes represented.. how can you tell if a parent is a object or a list.. inserting a item into a list is a ton of error prone renames.. the list goes on
(edited for formatting)
Re: The File Filesystem (2021)
#99Oh 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…
This makes me think, it would be nice if there was an easy built-in way to expose information about a process using the filesystem. Something like "cat /proc/$pid/fs/current_track" to get a name of a current song from a music player, or "ls /proc/$pid/fs/tabs" to list open tabs in my browser (and maybe use this to grab the html or embedded images). I mean right now it's possible to do this using FUSE, but that's conv…
Can you actually write to the /proc directory? Working with libfuse I've had much of the same ideas, basically allow programs to expose information as files. The beauty of the fuse system is also that you only have to respond to requests when they happen. So you don't have to actually create all these files until someone asks for them. Another idea I've had is to expose the configuration of a program through a filesystem. Instead of having a config file and a refresh command or a complicated IPC you could simply write to files to change the config.
Re: The File Filesystem (2021)
#100Earlier quoted context omitted.
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!
Not PMunch, but bindings¹ and statusbar². Nimble has a couple of fuse projects and wrappers registered too. ¹ https://github.com/PMunch/libfuse-nim ² https://github.com/PMunch/statusbar
The audio player is unfortunately not on GitHub yet, I've still got a few kinks to work out before it's in a shareable state. The statusbar project was also shared mostly so the other Nimdow users could play around with it, so the code quality is quite sub-par.