Goliath

There is now "new squashfs", there are new tools, that try to be compatible with the Linux kernel code. This now looks like a compatibility problem on our end. 7-zip uses the size stored in the inode, but the Linux kernel SquashFS does not, it uses the size stored in the directory header, so it doesn't matter if the length is off by 3. This is why the problem didn't show up sooner. This is the closest I have to a specification from reverse engineering the kernel side of the code, but it (right now)...

The code I was referring to, is this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/squashfs/dir.c#n50 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/squashfs/dir.c#n115 The size is padded by 3 byte and when reading at an offset < 3, "." and ".." are returned. My guess was, that this might be where this difference comes from. The attached archives contain exactly 1 file each (under the root directory). Inodes and directories are uncompressed....

Is this perhaps derived from the readdir() code in the squashfs kernel module? The kernel code at one point adds 3 to the directory size and then in readdir checks if the offset is < 3 to return artificial . and .. entries. Other than that I don't know of any padding inode or file padding.

The attached test.sqfs was generated from the squashfs-tools-ng doc directory using mksquashfs and works. The second file, test2.sqfs was generated by running it through squashfs-tools-ng tar2sqfs like this: sqfs2tar test.sqfs | tar2sqfs test2.sqfs. It does not appear to work on my end using 7-zip 16.02.

Cannot unpack squashfs images created with squashfs-tools-ng