From 05e88d9b9a175a83a4f9978c42e574ca6bbc6ffb Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Tue, 18 Dec 2012 11:22:03 -0600 Subject: [PATCH] Update NEWS and README --- NEWS | 29 +++++++++++++++++++++++++++++ README | 19 ++++++++----------- 2 files changed, 37 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index 5a33cefa..37f8bc0f 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,34 @@ Only the most important changes more recent than version 0.6 are noted here. +Version 1.2.1: + By default, unmounting a read-write mounted WIM with 'imagex unmount + --commit' will now change the WIM in-place without needing to write the + entire WIM again. Use 'imagex unmount --commit --rebuild' to get the + old behavior. + + 'imagex unmount' no longer has a hard-coded limit of 10 minutes to wait + for a response from the daemon servicing the mounted WIM. Instead, + every second 'imagex unmount' will check if the daemon is still alive, + and keep waiting if so, otherwise terminate with an error. + + 'imagex unmount --commit' on a read-write mounted WIM will now print + progress information regarding the writing of new or modified streams + the WIM, just like when capturing or appending a WIM. + + A small change has been made to XPRESS compression and it should improve + the compression ratio slightly. + + Microsoft has managed to introduce even more bugs into their software, + and now the WIMs for Windows 8 have incorrect (too low) reference counts + for some streams. This is unsafe because such streams can be removed + when they are in actuality still referenced in the WIM (perhaps by a + different image). wimlib will now work around this problem by fixing + the stream reference counts. This is only done when wimlib_delete_image() is + called ('imagex delete') or when wimlib_mount_image() is called with + WIMLIB_MOUNT_FLAG_READWRITE ('imagex mountrw'). Please note that this + requires reading the metadata for all images in the WIM, so this will + make these operations noticably slower on WIMs with multiple images. + Version 1.2.0: Appending images to a WIM is now be done by default without re-building the whole WIM. Use the --rebuild flag to get the old behavior (which diff --git a/README b/README index caf0238d..d4b4ed1f 100644 --- a/README +++ b/README @@ -48,12 +48,12 @@ not capture/split/join/append/export/mount a WIM. See `programs/wimapply.c'. COMPRESSION RATIO -wimlib can create XPRESS or LZX compressed WIM archives. As of wimlib v1.0.3, -the XPRESS compression ratio is slightly better than that provided by -Microsoft's software, while the LZX compression ratio is approaching that of -Microsoft's software but is not quite there yet. Running time is as good as or -better than Microsoft's software, especially with multithreaded compression, -available in v1.1.0 and later. +wimlib can create XPRESS or LZX compressed WIM archives. Currently, the the +XPRESS compression ratio is slightly better than that provided by Microsoft's +software, while the LZX compression ratio is approaching that of Microsoft's +software but is not quite there yet. Running time is as good as or better than +Microsoft's software, especially with multithreaded compression, available in +wimlib v1.1.0 and later. The following tables compare the compression ratio and performance for creating a compressed Windows PE image (disk usage of about 524 MB, uncompressed WIM size @@ -62,16 +62,13 @@ a compressed Windows PE image (disk usage of about 524 MB, uncompressed WIM size Table 1. WIM size XPRESS Compression LZX Compression - wimlib imagex (v1.0.2): 145,283,871 bytes 139,288,293 bytes - wimlib imagex (v1.0.3): 139,288,293 bytes 131,379,869 bytes + wimlib imagex (v1.2.1): 138,971,353 bytes 131,379,943 bytes Microsoft imagex.exe: 140,406,981 bytes 127,249,176 bytes Table 2. Time to create WIM XPRESS Compression LZX Compression - wimlib imagex (v1.0.2): 18 sec 49 sec - wimlib imagex (v1.0.3): 19 sec 30 sec - wimlib imagex (v1.1.0, 2 threads): 11 sec 17 sec + wimlib imagex (v1.2.1, 2 threads): 11 sec 17 sec Microsoft imagex.exe: 25 sec 89 sec NTFS SUPPORT -- 2.43.0