wimlib

It may have been a good idea to do this originally. There would still need to be an option to always create a new archive, rather that potentially use an existing archive; it just wouldn't be the default behavior. Changing it now is worth considering, but I am concerned that the change would cause c...

I'm not sure I understand your problem and how your proposed feature relates to it. Are you saying that the wimapply process is being killed before it has finished? If so, that isn't the fault of wimapply. You need to ensure that it is allowed to run to completion. The details of exactly what it doe...

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 ...

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...

It's the other way around. ntfsfallocate is another example of an application which uses libntfs-3g and the underlying ntfs_attr_truncate_solid() function and cluster allocator. Technically, I think ntfsfallocate wouldn't encounter this fragmentation problem because it only allows processing one fil...

One possibility is that the image's metadata resource compresses to a slightly different size each time because the timestamps are different. There could be other differences introduced while the image is mounted as well. There are no differences introduced by 'wimoptimize' itself since that process...

I did some tests with applying a Windows 7 image to an NTFS volume (~40000 files and 5 GB of data; volume size ~15 GB). In the case of nondirectory files, I found that wimlib is correctly requesting that NTFS-3G preallocate clusters. Before writing anything to a file stream, wimlib calls ntfs_attr_t...

Okay. Is there any specific way I can reproduce this problem? When I tried, there was little fragmentation.

Hi,

Do you know whether the fragmented files you observed were compressed with NTFS compression?

I can't help much with C#, but it should be possible to use the progress callbacks. Look for examples of implementing a callback function (callable from unmanaged code) in C#.