Eric Biggers [Mon, 19 May 2014 17:05:11 +0000 (12:05 -0500)]
Merge branch 'new_extract'
This rewrites much of the extraction code to give more freedom to
extraction backends about how they extract the files. This has
advantages for all three backends:
UNIX: Now does a lot fewer path lookups and should exhibit better data
locality. Final "set timestamps" pass only processes directories, since
nondirectory timestamps are set before that point.
NTFS-3g: Now completely based on inode numbers; no paths are ever
created, unless a printable path is needed for an error message. Got rid
of final "set attributes" and "set timestamps" passes, since all
attributes and timestamps are set before that point.
Windows: Now uses NT paths relative to the target directory, performs
fewer path lookups, extracts encrypted files without individually reading
ranges from the WIM (expensive for ESD files), and a few other changes.
A lot of code previously in the generic file extract.c actually could be
moved here.
Also, there are no longer any temporary files needed. All three backends
simply write all the instances of each stream at the same time, which is
more efficient.
Still TODO:
- New format for UNIX data
- Add fallbacks for when number of open files gets too high
- Add fallback for huge encrypted files
- If possible add hardlink and symlink modes back, however these
are pretty useless.
Eric Biggers [Sat, 17 May 2014 06:09:06 +0000 (01:09 -0500)]
inode_fixup.c: Further simplify MS bug workaround
Based on what WIMGAPI does, and assuming it sufficiently works around its
own [presumably fixed] bug, the workaround can be simplified to just
"don't hard link dentries that have different unnamed data streams".
Eric Biggers [Sat, 17 May 2014 03:08:16 +0000 (22:08 -0500)]
inode_fixup.c: Simplify logic
Most of the logic in this file is working around a Microsoft bug, but
there must be an easier way to do it. This commits strips the code down
to something more logical that still seems to "do the right thing" on a
Windows 7 WIM affected by the Microsoft bug.
Eric Biggers [Fri, 16 May 2014 01:13:34 +0000 (20:13 -0500)]
Rewrite code for capture rpfix
The previous code had many potential problems on the Windows side.
Targets of Windows native symbolic links (except those with
SYMBOLIC_LINK_RELATIVE set) and junction points are stored in the reparse
points as NT namespace paths. Therefore they can validly include
prefixes like '\??\', '\DosDevices\', or '\Device\HardDiskVolume1'. They
potentially do not use drive letters at all, and they may be over
MAX_PATH characters. Such paths should be accessed using the native API
(NtOpenFile), not Win32 (CreateFile). This commit changes the code to do
so.
With wimlib_reference_resource_files(), the resource WIMs are never made
accessible to library users, so there is no need to retain copies of all
stream entries in their lookup tables.
Eric Biggers [Mon, 12 May 2014 20:19:43 +0000 (15:19 -0500)]
add_image.c: Cleanup
Including:
- Use wimlib/security.h instead of wimlib/capture.h
- Replace add_new_dentry_tree() with add_empty_image_metadata()
(the root dentry is always NULL)
- Improve comments
Eric Biggers [Sun, 11 May 2014 05:23:34 +0000 (00:23 -0500)]
Don't create unnecessary temporary files
A temporary file is unnecessary (without too much extra trouble) if the
whole stream data is already in memory as a result of reading a packed
resource.
Eric Biggers [Sat, 10 May 2014 02:56:22 +0000 (21:56 -0500)]
wimcapture, wimexport: With --pack-streams, default to LZMS compression
This is not too important as the compression format of packed resources
is independent of the WIM's main compression format, but it makes sense
to also default to LZMS for non-packed resources (e.g. metadata).
Eric Biggers [Fri, 9 May 2014 01:46:18 +0000 (20:46 -0500)]
Allow writing multiple packed resources per WIM
... subject to the weird way that WIMGAPI interprets them.
Also:
- Write packed resource by default when updating version 3584 WIM
- Enable raw copy of packed resources (must be writing at least 2/3
the constituent streams)
Eric Biggers [Fri, 9 May 2014 00:54:01 +0000 (19:54 -0500)]
read_wim_lookup_table(): Allow multiple "subpacks" per packed run
Apparently WIMGAPI does, in fact, support multiple packed resources per
WIM. It creates them when exporting, and probably when appending too.
However, the format of the resulting lookup table is a little different
than I had expected, since it seems to be required that all the packed
resource metadata be combined into a single, mostly unordered run of
entries with the 0x10 flag set. This commit updates the read-side code
with this new assumption.