Update hyperlinks Use https whenever possible, and replace some outdated links.
wimlib_iterate_dir_tree(): don't checksum unhashed blobs wimlib_iterate_dir_tree() on a modified-but-not-committed image is very slow because it checksums all unhashed blobs. This was originally implemented by commit 681faad85f73 ("wimlib_iterate_dir_tree(): checksum unhashed blobs"), presumably to make the sha1_hash field always valid. However, I can't remember a real use case for this. The current behavior is causing problems, so let's just revert it and update the documentation accordingly. Reported at https://wimlib.net/forums/viewtopic.php?f=1&t=572
Improved year 2038 safety Make wimlib on 32-bit Windows year 2038 safe by doing the following: - Build both the library and program with 64-bit time_t, being careful to avoid changing the timespec struct exposed in the API. - Update wimlib's API to include an extended seconds field in wimlib_dir_entry for each timestamp, and set it when tv_sec is 32-bit. - When needing the current time, call GetSystemTimeAsFileTime() instead of MinGW's gettimeofday(). This also has the advantage that due to switching to the 64-bit time_t functions, 32-bit wimlib-imagex.exe now prints timestamps prior to year 1970 correctly. Unfortunately, despite the API improvement, we cannot at this time make wimlib fully Y2038-safe on 32-bit UNIX, due to lack of OS support.
wimlib.h: define timespec for MSVC compatibility
Unify case-sensitive and case-insensitive filename indices
Character encoding and string conversion updates - Allow unpaired surrogates when translating between "UTF-8" and "UTF-16LE". This allows Windows-style filenames to be processed losslessly on UNIX-like systems, even if they are not valid UTF-16LE. - Implement UTF-8 and UTF-16LE codecs ourselves and drop the iconv requirement. This was necessary to allow surrogate codepoints, but it also provides better performance and actually results in *fewer* lines of code and a slightly smaller binary. - Drop support for multibyte encodings other than UTF-8 on UNIX-like systems. It is probably not worth the effort to support such encodings. Interestingly, the support was entirely broken before v1.9.1, yet no one ever complained...
Make 'wimdir --detailed' show object IDs
wimlib_iterate_dir_tree(): free d_full_path after using
Rename _full_path => d_full_path
Rename dentry name fields file_name => d_name file_name_nbytes => d_name_nbytes short_name => d_short_name short_name_nbytes => d_short_name_nbytes
New helper function: inode_has_security_descriptor()
wimlib_iterate_dir_tree(): checksum unhashed blobs
Stream and blob updates - Rename "lookup table entry" to "blob descriptor" - Rename "lookup table" to "blob table" - Use single array for all an inode's streams - Explicitly annotate each stream with its type - Account for fact that EFSRPC raw data includes all data streams - Other cleanups
wimlib_iterate_dir_tree(): iterate in default case order
inode.h, inode.c cleanup
Use LGPLv3+ for src/*.c
struct wim_dentry: Rename 'parent' to 'd_parent'
Add support for special files on UNIX
Recognize tagged metadata items and use for UNIX data This is undocumented, but the Microsoft implementation seems to allow variable-length, tagged metadata items to be appended to WIM dentries. Currently it uses them for Object IDs, which DISM (Windows 8.1) will backup and restore by default. This commit adds support for these items, so they can be read and written unmodified. In addition, for our UNIX data extension, instead of storing the UNIX data in the reserved fields of the dentry or in alternate data streams, store it in a custom tagged item with a randomly chosen tag. This is perhaps the best choice compatibility-wise.
New format for UNIX data This moves the UNIX data into reserved fields of the WIM dentry. This is theoretically less extensible than the previous format, which was to add a specially-named alternate data stream entry to each file with UNIX data. However, having the UNIX data present in the metadata resource is simpler and avoids problems when doing sequential extraction. For now, this also seems to maintain compatibility with the MS implementation, since it seems simply ignore the reserve fields. Also, use 32-bit uids, gids, and modes.