[Feature request] Important change in squashfs core

[mdziczkowski]

I would like to request an quite important changes in the squashfs core code:

1. make a possibility that while creation the user can select with permission it should have - either be read-only (current) or be a read-write one.

2. add option that the squashfs ask where (path, destination folder name) it should extract the files instead of using the default folder name and the current path of the squashfs file

---

Explanations:

I had requested this feature because of:

• if it would exist a read-write version then it be would easer and faster to maintanance and upgrade of the squashfs without need to extract it to do changes and then to rebuild it again

• on the example of AppImage, the current version of squashfs (in with format the files are stored in it) causing very annoying problems (mainly the permissions one because it's beeing mounted as read-only, when some apps require read-write ones)

[Dr-Emann]

The read-only-ness of the squashfs format is kinda baked in to the format itself, squashfs optimizes for size, not updatability.

Files in a squashfs archive are split into chunks, each chunk is compressed, then they are stored, one after the other. If you were to modify the content of the first block of a file, such that it compresses slightly worse (not even changing the size of the file), what do you do? That first block is now larger, which means you have to move all the later blocks of the file. And the files are all packed one after the other, now you need to move all the files after that one (and update the information about where those files are located). Now you've basically re-written the whole archive, all because you changed the content of one file inside!

If you want an updatable image, I believe you should look for a different format than squashfs.

[mdziczkowski]

Thanks for the reply. It's not my fault that some apps (like for example AppImage) use squashfs ;-)

I had wroten it to allow find a possible workaround with could fix the mentioned by you issue, without loosing the compression.

My idea has a simple process. I'll give it on an example bellow:

The squashfs is mounted on /mnt/squash (it would work as buffer in between the squashfs file and system) and the administrator want edit and save the changed file "x". A working in background squashfs-tools dynamicaly:

• find the changed file in the squashfs file and extract only it (instead of whole squashfs file) into /tmp folder
• the old file (in /tmp) becomes replaced in by the changed one
• the replaced file is beeing compressed back into squashfs file

[svet-b]

@mdziczkowski doing the sort of on-the-fly updating of a squashfs image that you describe would be quite resource-intensive and not useable in practice. If you need to update some files ad hoc (as you describe), then the only real way would be to manually extract and re-pack the image, as described in the top answer to this StackExchange question.

On the other hand, if you need to have genuine read-write capabilities then the way to achieve that is with a writable "overlay" mount on top of the squashfs mount. The second answer in the link above describes this scenario. Hope that helps!

[mdziczkowski]

@svet-b Hello and thanks for the answer.

I twought more about such solution:

Defaultly, for the less experienced (normal) users it would remain as is - read-only, but there should be a possibility for more adwanced users to enable the write

[plougher]

To update a file in a Squashfs filesystem requires unpacking and rebuilding. To put it simply, a Squashfs filesystem is like a brick wall, each successive layer depends on the layers below. You can't pull a brick out of the middle of a wall, instead you have to dismantle it, replace the brick and rebuild it.

There's no pointing asking that Squashfs be made read-write. It is not going to happen, especially as there are loads of read-write filesystems you can use.

If your issue is XYZ (insert-random-project here) forces you to use Squashfs, and you want a read-write filesystem, raise the issue with them.