wimlib

Hi Synchronicity,

Would it be possible allow user to retrieve the sha1 of a file by giving a path?
A Python API would really be awesome

Regards

Hi Synchronicity,
Just to wish you a happy new year. It's always a pleasure to work with wimlib. All the best for you and wimlib in 2017
Regards

By the way, any chance to changed the hard coded 16 (Kbyte or Mbyte don't remember) hole after each file anytime soon in NTFS-3G?

such as my NTFS-3G plugin for system compression (https://github.com/ebiggers/ntfs-3g-system-compression). Nice :) If it's now supported in Linux, I'll try to get it working on Windows 7 (I read it is possible to "backport"). A chunk size like 128 KiB would be more reasonable. For anyone ...

Oh and why not create a fork of ntfs-3G or submit patches? Wimlib is certainly the application which has the most intensive usage of ntfs-3G when applying huge partition images. What you would do with it could only benefit the other applications using it.

Hi,
Wimlib is already the fastest and most storage efficient archiver we got in our real use case. And you manage to still improve performance

For some people, not getting spammed with annoying "are you sure?" prompts is a feature. Microsoft ImageX and DISM do not use prompts either. Is understandable. Then capture could be the way to always create a new archive and append would only create one if their is no archive with given ...

Good Idea, in the meantime, asking the user if he want's to overwrite the existing file (for capture) or if he wants to create the archive (in case of append) would be safe. I agree that automatically creating the archive if it doesn't exist for append should be safe. For capture I would also keep i...

Thanks for the clarification Synchronicity Maybe a quick solution in the meantime would be to first write the bigest files and then the smallest, they would better fit in the gaps without fragmentation and the big files would then be contiguous. Maybe as an option to only use it when beneficial.

Thanks for the investigation. Does ntfsfallocate have the same 16MB "buffer" problem (or is ntfs_attr_truncate_solid() the way to call ntfsfallocate)?
If it's really a failed design, I hope it get fixed soon upstream.