This discussion happened via email. This will be fixed in 5.4.1. Thanks!
Dear Lasse Collin Hello, I am the author of the xz-utils C# wrapper, Joveler.Compression.XZ. I found xz-utils 5.4.0 MSVC build script is imperfect, and it omits several symbols which should have been exported. Summary xz-utils 5.4.0 introduces multithreaded decompression support, with 'lzma_stream_decoder_mt'. However, liblzma.dll built by MSVC2019 does not export lzma_stream_decoder_mt symbol. In fact, the dll does not have the function compiled. The main reason is that 'windows\vs2019\liblzma_dll.vcxproj'...
As of now, there is no such option to only overwrite the file based on a timestamp check. You can force overwrite as a work around with the -f , --force option to avoid throwing an error and aborting your script. This will not help with avoiding the extra time to extract your files. That would require an extra option that does not currently exist. If you have time and want to contribute this feature, it would be considered. Unfortunately, it is not a priority so I am not planning on working it anytime...
no, not the date of the .xy file, but the date of the files being extracted compared to what might be on disk. I don't want this to happen: xz --keep --decompress 2022-04-04-raspios-bullseye-armhf-lite.img.xz xz: 2022-04-04-raspios-bullseye-armhf-lite.img: File exists This throws an error, and aborts my script. also these are big files, so I would rather not take the time to extract just to find out I didn't need to.
Add function seek.
I made a small example of using the XZ Utils library to create and read archives (just like in zlib). It was quite difficult for me to understand the logic of the archiver using examples, so there may be errors. But on my data, this approach works well. https://github.com/magicwolf2019/XZ_FIle
Thanks! Mostly liblzma-native relies on prebuilds for all platforms, so building from source, while a fallback, is almost an error condition. For this (fully automated) fallback I guess it makes sense to assume as little as possible about the build tools available, and autotools or cmake is a big ask vs just a C compiler. Prebuilds for darwin-arm64 have been made, so I guess liblzma-native is happy and can wait until the next official release of XZ Utils that includes updated autotools files.
Hi! Thanks for including the patch. The patch you linked modifies the config.sub file, which is generally against best practices. The config.sub file is maintained and released by autotools. Using CMake may solve your issue, but it is somewhat experimental on non Windows MSVC for liblzma. The next alpha release should happen in February and it will have some patches to CMake. I don't believe the next release will have the config.sub patch you are proposing, especially if you can use autogen or CMake...
Hi! Just to clarify, are you looking for a command line option to check if the modification date / creation date on (filename).xz is newer than the modification date / creation date on (filename)? As of now, there is no such command line option to accomplish this, but it would be straightforward to wrap xz in a script to test for this.
Hi, It's more than 2 years since 5.2.5 was released, and during this time there's a new architecture on the market! Currently the ./configure in 5.2.5 fails if run on the new Apple M1 Macs (darwin-arm64) and require patching config.sub - see https://github.com/addaleax/lzma-native/pull/123 Just re-running ./autogen.sh will create a working configure setup for M1 macs, but it requires a bigger build chain (with autoconf etc) that many people don't have. Would you consider releasing patch release (5.2.6?)...
wget -N http://raspi.debian.net/daily/raspi_4_bullseye.img.xz xz --keep -vv --decompress raspi_4_bullseye.img.xz Is there an option to only decompress newer files?
Hi Lasse! Thanks for all your comments. I worked to make the changes you suggested, and it work well with the lib provided with Ubuntu 20.04 like that. I had to set the LZMA properties byte (lc/lp/pb) to 0 though, or it wouldn't work. I'm not sure about the implication, but I feel I'm lucky I managed to make it worked in the first place on my side. So I discoved jffs2reader is part of mtd-utils, which is managed by a linux-mtd, which is a sub-team from the linux kernel. Not sure it'll get integrated...