The old Makefile + config.h was deleted, because it
becomes outdated too easily and building with the
Autotools based build system works fine even on Windows.
windows/build.sh hasn't got much testing, but it should
work to build 32-bit x86 and x86-64 versions of XZ Utils
using MSYS, MinGW or MinGW-w32, and MinGW-w64.
windows/INSTALL-Windows.txt describes what packages are
needed and how to install them.
windows/README-Windows.txt is a readme file for the binary
package that build.sh hopefully builds.
There are no instructions about using Autotools for now,
so those using a git snapshot may want to run
"autoreconf -fi && ./configure && make mydist" on a UN*X
box and then copy the resulting .tar.gz to a Windows.
If signal handlers haven't been established, then it's
useless to try to block them, especially since the sigset_t
used for blocking hasn't been initialized yet.
The opening of the destination file is now delayed a little.
The coder is initialized, and if decompressing, the memory
usage of the first Block compared against the memory
usage limit before the destination file is opened. This
means that if --force was used, the old "target" file won't
be deleted so easily when something goes wrong very early.
Thanks to Mark K for the bug report.
The above fix required some changes to progress message
handling. Now there is a separate function for setting and
printing the filename. It is used also in list.c.
list_file() now handles stdin correctly (gives an error).
A useless check for user_abort was removed from file_io.c.
This is a bit rough but should be useful for basic things.
Ideas (with detailed examples) about the output format are
welcome.
The output of --robot --list is not necessarily stable yet,
although I don't currently have any plans about changing it.
The man page hasn't been updated yet.
Thanks to Dan Shechter for the patch.
It is likely that windows/Makefile will be removed
completely, because Autotols based build nowadays
works well with both 32-bit and 64-bit MinGW (I
just need to update the docs).
to stdout even if --force is used.
--force will still enable compression of symlinks, but only
in case they point to a regular file.
The new way simply seems more reasonable. It matches gzip's
behavior while the old one matched bzip2's behavior.
This breaks API and ABI but most apps are not affected
since most apps don't use this part of the API. You will
get a compile error if you are using anything that got
broken.
Summary of changes:
- Ability to store Stream Flags, which are needed
for random-access reading in multi-Stream files.
- Separate function to set size of Stream Padding.
- Iterator structure makes it possible to read the same
lzma_index from multiple threads at the same time.
- A lot faster code to locate Blocks.
- Removed lzma_index_equal() without adding anything
to replace it. I don't know what it should do exactly
with the new features and what actually needs this
function in the first place other than test_index.c,
which now has its own code to compare lzma_indexes.
Since the *.gmo files are deleted by the maintainer-clean target,
I assume they are not meant to be tracked.
Also add the other files listed in the Makefile’s clean targets
(stamp-poT, xz.po, xz.[12].po, *.new.po, xz.mo) to make sure they
are not accidentally tracked. Most of these are intermediate
files that would not appear unless a build is interrupted or
fails.
Split the list of untracked files by origin to make it easier to
tell if files are missing in the future.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks to Marek Černocký.
Other people planning to translate xz: Note that the
messages are a little bit in flux still. Translations
are still welcome, just be prepared to some extra work
in case there are changes.
lzma_index_read() didn't skip over Stream Padding
if it was the first record in the Index.
lzma_index_cat() didn't combine small Indexes correctly.
The test suite was updated to check for these bugs.
These bugs didn't affect the xz command line tool or
most users of liblzma in any way.
The Index decoder code didn't perfectly match the API docs,
which said that *i will be set to point to the decoded Index
only after decoding has succeeded. The docs were a bit unclear
too.
Now the decoder will initially set *i to NULL. *i will be set
to point to the decoded Index once decoding has succeeded.
This simplifies applications too, since it avoids dangling
pointers.
a regular file.
Sparse file creation can be disabled with --no-sparse.
I don't promise yet that the name of this option won't
change before 5.0.0. It's possible that the code, that
checks when it is safe to use sparse output on stdout,
is not good enough, and a more flexible command line
option is needed to configure sparse file handling.
Lasse Collin
Jonathan Nieder