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.
Eric Biggers [Tue, 29 Apr 2014 19:13:41 +0000 (14:13 -0500)]
Adjust path matching
- To get consistent behavior, always use own implementation in
wildcard.c, not fnmatch() or PatchMatchSpec()
- Don't store prefix in capture config
- Don't allow non-rooted paths with multiple directory components (these
could cause confusion)
- win32_apply.c: Match [PrepopulateList] patterns recursively
Eric Biggers [Tue, 29 Apr 2014 16:22:06 +0000 (11:22 -0500)]
More logical behavior when canonicalizing WIM paths
In addition to translating path separators and stripping trailing
slashes, also collapse consecutive path separators, and retain the
leading slash to emphasize that the paths are rooted.
Add WIMLIB_WIM_ROOT_PATH and WIMLIB_IS_WIM_ROOT_PATH macros to wimlib.h.