wimlib can't handle case sensitive names on Windows 10

[chungy]

The recent Windows 10 update includes the Windows Subsystem for Linux, and by installing it, the default image contains names that differ only in file case (see lxss/rootfs/usr/share/terminfo for example). wimcapture on Windows runs without any apparent error, but will only capture the upper-case version of the files/directories and duplicate that for the lower-case version. Running wimcapture from Linux, giving it the Windows 10 NTFS volume block device, works as expected. In either case, wimapply at least warns about being unable to extract the differing-case names.

Dism has the same behavior, so at least it's no worse than Microsoft's program. cmd likewise isn't able to show directory listings for the lower-case version of subdirectories in terminfo.

For the moment, this means wimlib is incapable of capturing/applying lxss from Windows itself, possibly other weird corner-cases that aren't usually caught because Windows systems are almost always case-insensitive.

(Also of note: lxss is also capable of creating file names with invalid Win32 name characters, but this seems to be implemented in a manner similar to Cygwin, by remapping special characters to another string. The old Interix system didn't do that, and stored control characters, wild cards, etc directly. My bets are that wimlib doesn't handle it either, but I haven't tried.)

[chungy]

Looking at how lxss is implemented, this might be tricky. I assumed that it set obcaseinsensitive to 0 as described in the Cygwin documentation -- it allows Win32 processes (such as Cygwin) to access/create files with case sensitivity

This doesn't appear to be true on Windows 10 with the Subsystem for Linux installed. obcaseinsensitive remains at 1, but lxss bypasses the normal subsystem architecture entirely, and has the ability to handle case sensitive names (even under the /mnt/?) regardless of the registry key. Even Cygwin is unable to see unique files that differ in case on a default installation.

Still, I think it might be possible to get wimlib to work as intended with the registry setting. More far-fetched, maybe even a special ELF binary intended for lxss only, that's able to perform a directory capture (and apply) with full case sensitivity intact, but I don't think this will be reasonably possible.

[synchronicity]

If such files can only be read by a Linux binary, then it's not realistic to make the Windows version of wimlib handle them. It would have to do something very convoluted like spawn a Linux binary and communicate with it using an IPC protocol. And that would need to happen for both capture and apply.

You could, however, just build wimlib for Linux and use that. I can't tell you whether it really works on "LXSS" or not since no one has reported testing it, but it does work on real Linux!

Note that the file metadata available through the Windows and Linux APIs will be quite different.

[chungy]

They can be read by Win32 processes, if obcaseinsensitive is set to 0. Cygwin is capable of reading through it, as an example. I'm thinking wimlib might be able to use case-sensitivity assuming the registry flag is set. It's unfortunate that lxss doesn't obey the normal rules and is always case-sensitive. I'm actually a little surprised that's permitted by Windows.

Part of my intention was to use wimlib to backup the lxss tree and restore it. Playing around with different things inside of it, but it's stopped short by this limitation.

The Linux version of wimlib should work, but would retain none of the NTFS metadata, the best that can be obtained is via --unix-data. It'll be nicer for a native capture/apply to work, especially so that VSS snapshotting still works.

[synchronicity]

Yes, but it seems that obcaseinsensitive=0 is not guaranteed by installation of LXSS, so I think the functionality wouldn't be used often.

I am not sure anyone has ever tested wimlib with objcaseinsensitive=0. Currently, I expect that capture will work as expected but apply will not. The extraction code would need to be made aware of whether case sensisitive filenames are supported or not. I will think about it.

[chungy]

Thanks, just did another small test. capture works properly with obcaseinsensitive=0, all the case variations are stored as their proper types and contents. apply is still an issue, but it'll be good if that can change in the future.

[synchronicity]

I've updated wimlib to honor the obcaseinsensitive=0 registry setting when extracting. It was actually a fairly trivial change since the Windows extraction code effectively already honored the setting; it just needed to declare that case sensitive names are supported, when they are. You can find the change included in v1.10.0-BETA5 if you want to test it.

[chungy]

I didn't get back to you earlier, but the change has worked great, thank you.

Not-so-great is how Windows 10's LXSS interacts with ObCaseInsensitive. To put it simply, when 0, the subsystem is incapable of starting at all. So we've got a registry setting that's supposed to tell the kernel to be (or not to be) case-insensitive, but a subsystem that ignores it and is _always_ case-sensitive, and when you make Win32 case-sensitive too, it doesn't start. :X

I doubt this is something wimlib can reasonably fix at all (not without being ported to run as a pico process and abandon pre-W10 Update compatibility). Still, with Cygwin and Interix, it has been possible to use case-sensitivity, provided the registry key is set to 0, and wimlib is at least capable of capturing and applying those trees perfectly.