wimlib

Adding some assertions might be a good idea.

But again, the required alignment is no more than the natural alignment, i.e. __alignof__(struct avl_tree_node). That's either 4 or 8. So even if the code didn't use the bottom two bits of parent_balance for other information, it would still have ...

This is not a bug. The avl_tree_nodes are aligned to at least 4-byte boundaries in the actual code, so this issue does not occur. Note that their natural alignment suffices to achieve this.

Yes, that's fine with me. You can use the LZX code under LGPLv2. Thanks!

A lot of the memory used during compression is accessed randomly, not sequentially. So latency is super important, not just throughput. Having it be paged in and out of disk would be extremely slow. Probably multiple orders of magnitude slower which would easily defeat the point of using any more ...

That's strange. Is it possible that your setup.wim has an uncompressed size between 128 MiB and 256 MiB? That's the only case that I can think of where this would happen. wimlib checks whether the total uncompressed size of the file data is less than or equal to the chunk size (the chunk size that ...

I will update the warning message.

Just to clarify, WIM does support hard links. But it does not support symlinks that are hard linked to each other, which seems to be the case here. The fallback behavior is that wimlib stores the symlinks in non-hard-linked form.

Thanks! I might know what's causing this. Are all these files symlinks that are hard-linked to each other? If you run 'find /mnt/backup -inum 263330', for example, I think that 4 results will be found, and they will all be symlinks with the same target. Is that the case? If so, that means that your ...

I'm puzzled, then! Either the filesystem is reporting duplicate inode numbers (despite being ext4), or something is really going wrong in wimlib. Could you try applying this patch which adds an additional message for debugging?

Are there any bind mounts in /mnt/backup?

This indicates that the filesystem on that system does not provide unique inode numbers for directories, making it seem like directory hard links are present. What filesystem type are you are using? Presumably it's not something normal like ext4, but rather something more exotic?