libfuse VS squashfs-tools

I suspect if you've run into problems with a lot of things built on FUSE, the problem is FUSE.

Yes, s3fs and sshfs can both leave the system in an unstable state. For example, there can be a dead mount which is impossible to unmount, and in severe cases, blocks a clean reboot.

A file system in user space (or in network space) should NEVER break the system, no matter what happens in user space (or in network space). Most network file systems try to respect this (albeit with mixed success). FUSE does not.

I'm not claiming FUSE cannot be made to work. Just that it's very bad since (1) plenty of smart people clearly failed to do so (2) the badness it leaves behind should be more than it's permitted to.

I can point to specific issues, but at the end of the day, that's neither here nor there. At the end of the day, something like:

https://github.com/libfuse/libfuse/blob/master/example/poll....

Is about a hundred times more complicated than it should be. It should not require memsets, pthread mutexes, or flags, and should probably have an implementation in a modern, high-level language. To a large extent, that's the point of moving things out of the kernel.

I'm even perhaps okay with being permitted to do low-level operations for a particularly performance-constrained subsystem, but that's not 95% of the uses of something like FUSE.

Footnote: I actually enjoyed writing low-level code like this a lot, when computers were in the single-digit to triple-digit MHz range, and we didn't need to worry about people breaking in over a ubiquitous worldwide internet, but I left that mindset behind decades ago. Right now, I want code to be stable, simple, auditable, and secure.

I wrote the original version for a previous employer mostly in Python.

I was about to recreate a new version in Rust. And started with fixing up libfuse https://github.com/libfuse/libfuse/pulls?q=author%3Amatthias... and the Rust equivalent https://github.com/cloud-hypervisor/fuse-backend-rs/pulls?q=...

Your project is also interesting. I don't plan on ever adding write support. The old Python version was already using git as a library via gitpython, instead of shelling out via the command line. The new version will use Rust's gix.

Performance, even for the old Python version, was pretty decent. That probably came from using git via a library and being careful about fuse caching. The old version also already supported opening arbitrary commits, tags and branches, they were represented as different folders.

s3fs allows Linux, macOS, and FreeBSD to mount an S3 bucket via FUSE(Filesystem in Userspace). s3fs makes you operate files and directories in S3 bucket like a local file system. s3fs preserves the native object format for files, allowing use of other tools like AWS CLI.

FUSEs your files

The situation is much worse than I had imagined; the parent project, libfuse, is also in need of a maintainer.

https://github.com/libfuse/libfuse

You need to install a few dependencies, notably the SquashFS and FUSE, and Snap itself:

> Honestly I think you could be a little more respectful of the project that inspired yours.

I do. I had a lot of great "Huh? That's clever!" moments while reverse engineering the format and formed a mental image of a clearly brilliant programmer who managed to squeeze the last bits out of some data structures using really clever tricks that I myself probably wouldn't have come up with. During that time I gained a lot of respect for the project and the author.

Also, please don't forget: the whole project is the filesystem, the tools are just a part of that. I care about this project, which is why I decided to start this effort in the first place. Which I explicitly did not advertise as a replacement, but an augmentation (see [2]).

> I'd be angry too ... Definitely understandable.

Yes, I agree! And I can understand why in the heat of the moment you might write something angry and threatening. But certainly not if you've had a few weeks time to calm down and think things over.

> And you plagiarized part of his readme.

https://github.com/plougher/squashfs-tools/blob/master/RELEA...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

https://github.com/AgentD/squashfs-tools-ng/blob/master/READ...

Oh yes? Which part?

> ... calling it spaghetti code (which isn't immediately verifiable)

Here you go, have fun: https://github.com/plougher/squashfs-tools/blob/master/squas...

However, I cannot blame anyone here, I totally get how those things happen and have witnessed it myself in action:

You write a simple tool supporting a larger project. It's written by the seat of your pants without much planning, since it's not big and does one simple job. Then it gets used in production, eventually requirements change, other people pile on patches, but try to keep the diff small, so it's reviewable and it receives maybe a little less care than the actual project it supports. Nobody bothers to overhaul it or write documentation because, hey, it works, and any large changes might risk breaking things.

Even if nobody is to blame for it, the end result is still the same: an undocumented mess that is hard to wrap your head around if you aren't the original author, who is the only one with the bigger picture.

I tried for roughly a week to pull the code (there are some more files than this and some of the inter dependencies are nasty) apart into stacked utility libraries and a pure command line parsing front end, with the hopes to maybe get this upstream once it is done. I gave up and decided that at this point I understood enough about the format to start afresh and not touch what I believed to be an unmaintained mess.