Please try to actually read what I wrote in the first post. I'm not looking for workarounds - being an experienced unix system engineer I've got plenty of *nix based systems on hand. I'm curious about what's really going on under the hood.
Blaming "cygwin is bad" is an easy route for lazy people - it does not solve anything ;-). Nevertheless (a) I've got case sensitivity set up properly for cygwin (it is turned on for Windows kernel and for example OpenWrt's internal checks for FS case sensitivity pass OK) and (b) error in decompressing xz stream of data on SoC has extremely low chances to be caused by case-insensitivity. It is xz decompression error what's being reported, not some filesystem case sensitivity problem. As for byte/word ordering - linux host I used for tests in this case is a CentOS7 x86_64 VM running in VirtualBox alongside the Windows/Cygwin. Thus it is the same CPU/arch/endiannes. Plus you'd expect all block sizes to be screwed under cygwin if the problem was related to endianes.
Point here is that this is a developer's forum, isn't it? And developers tend to like working on solving complex problems, that's a kind of a game in itself. The entirety of my life I've been working in IT field doing complex thing and solving complicated troubles. Developers do things like this not because they are easy, but because they are hard and it is satisfying to have it solved yourself knowing that others gave up on this. For example if something that was designed to work under linux userspace fails under FreeBSD's emulation of it with the same set of userspace libraries used in both cases - it is not a matter of trust for me, it is more like a challenge and curiosity call as it means that either there are bugs or some assumptions in code that are needlessly linux-specific OR/AND it is a valid case of linux-only code that, maybe, is heavily reliant on some linux-specific system call or interface that is not provided by the emulation layer. Either way I want to know what's the deal as knowing the answer might reveal bugs and end up in making code more robust.
For this specific case we are not even talking about the firmware image creation under cygwin (while I had proven for myself that is is possible - take a look here). It's a matter of using a single standalone tool, mksquashfs. I hadn't provided details on the actual workload that is happening as it is not that relevant for the question itself but screw it, here it is:
- We've got a custom board with some vendor-shipped firmware and we have no access to and haven't got sources for. Looking at the bootlog over UART makes me believe that firmware is OpenWrt or LEDE based.
- We've got end-users using these boards for their needs and these users are ordinary people - they know nothing about linux, squashfs, e.t.c., e.t.c.
- Vendor's approach for providing data to the board is to insert an SD card into it. On a card there should be a single FAT32 partition with a file named
datafs.squashstored on it. This file is expected to be a squashfs 4.x filesystem storing user-specific data in a some vendor-defined folders structure. Don't ask me why vendor thought that this is a good idea - my guess would be that weeds were smoky at vendor's land by the time the decision was made. - Vendor provided a tool in a form of a bash script to be run under Ubuntu that automates the creation of a
datafs.squash. Rationale provided by vendor was that it is "cross-platform as it works both under linux and under Windows using WSL". Catch is that most of our end-users use Windows 7 or 8.1 thus having no access to WSL and they don't want/know/able to install/use Ubuntu VM on their PCs. - Conclusion for us was that it would be worth trying to re-implement vendors script using cygwin and check if that would fly. But it failed with board being unable to mount squashfs image that was generated under cygwin. So I started to debug the issue and was easily able to reproduce "unable to mount error" on BPi R2 board I was toying with during last several months. Then I went on and started to experiment with the way squashfs tools are compiled, with various compression options available in mksquashfs and found out all the info I provided in the first post of this thread.
That's basically it. I know what are the next possible debugging steps here but before taking a deep dive into it I posted the info here hoping that someone from experienced devs might have a better idea on what's going on that will save me from wasting tons of time on a tedious debugging.