squashfs-tools-ng.git/lib/fstream, branch v1.3.0

Cleanup: rename libfstream to libio, split headers

2022-07-08T17:17:35+00:00

Signed-off-by: David Oberhollenzer

Remove builtin copy of zlib

2022-04-10T20:48:34+00:00

On GNU/Linux, *BSD or MacOS we can simply use the system default library. The copy was primarily only there for the Windows build. The build script for Windows has now been adapted to download and compile a shared library from a tarball. This removes a huge chunk of code from the git tree as well as the release tarballs. Additionally it gets rid of iffy things like removing the Zlib copyright/version strings, so the libsquashfs DLL doesn't export it. Signed-off-by: David Oberhollenzer

Fix: Windows: libfstream: allocation size of stdout stream struct

2022-03-09T22:32:22+00:00

Signed-off-by: David Oberhollenzer

Fix: libfstream: don't fail on Windows when reading from a pipe

2022-01-29T15:08:16+00:00

When piping the output of another program into tar2sqfs.exe, and the source program terminates, tar2sqfs.exe gets an ERROR_BROKEN_PIPE when the end is reached and it trys to pre-cache more data. This commit adds a work around, to propperly handle this as and end-of-file condition. Signed-off-by: David Oberhollenzer

Fix: consistently use the widechar file API on Windows

2021-12-05T09:29:36+00:00

When opening files on windows, use the widechar versions and convert from (assumed) UTF-8 to UTF-16 as needed. Since the broken, code-page-random API may acutall be intended in some use cases, leave that option in through an additional flag. Signed-off-by: David Oberhollenzer

Fix: libfstream: Correctly handle FlushFileBuffers resturn status

2021-11-24T11:33:57+00:00

The Windows port uses FlushFileBuffers in libfstream for the implmentation of the file flush method. Unlike other winapi functions, this function returns a boolean and not an error code. Previously, the error code path was executed on success, printing a rather confusing error message, that this file already exists. Signed-off-by: David Oberhollenzer

libfstream: sanity check the buffer size in the gzip stream compressor

2021-06-25T13:15:05+00:00

Signed-off-by: David Oberhollenzer

libfstream: guard against potential integer overflows

2021-06-25T13:12:41+00:00

The differen compressor libraries use differnt integer types to tally the buffer sizes. The libfstream library uses size_t, which may be bigger than the actualy types, potentially causing an overflow if trying to compress to much at once. Signed-off-by: David Oberhollenzer

Fix: allow concatenated Bzip2 streams

2021-06-04T10:16:55+00:00

This is a followup to dd4e6ead142e58568aec89d76b0b2e867ee983f2. Basically the same problem occours with Bzip2, but it so far it wasn't possible to find a sampel that reproduces it. Unlike libxz, the libbz2 API does not support concatenated streams by itself and will choke when trying to decompress after the stream end, so this commit adds a workaround to simply initialize the decompressor on-the-fly and tear it down again when and end-of-stream is returned. The end-of-file condition is only set when there actually is no more data to read. Otherwise, the decompressor will be re-initialized in the next round. Signed-off-by: David Oberhollenzer

Fix: allow concatenated xz streams

2021-05-06T11:27:46+00:00

Some xz compressed tarballs (e.g. from kernel.org) are not made up of a single xz stream, but rather contain several, independendly compressed streams. In that case, the xz decompressor hits an LZMA_STREAM_END early on and reports EOF. If you are lucky, the tar reader bails (premature end-of-file). If you are unlucky, it happens exactely between two records and is interpeted as regular end-of-file. As this seems to be a normal use case for xz, it has a flag to just read across the seams and only report end-of-stream if the action is set to finish. This commit adds the flag to the initialization propperly sets the lzma_action depending on whether the underlying stream hit EOF or not. Signed-off-by: David Oberhollenzer