[SOLVED] tar.bz2 content partially corrupted when extracted via GUI

schard · 2026-07-28 10:33:45

I am using Gnome as a DE, nautilus as a file manager.
I have a .tar.bz2 archive, that, when I extract it via the file manager, i.e. double-click on the archive file in nautilus, will result in one file being not properly extracted from the archive.
When I extract the very same archive using tar in the console, however, the file extracts correctly.
I'd appreciate any pointers as to what might be the issue here.

~/Downloads> cd test/
~/Downloads/test> ls
╭───┬───────────────────────────────────────────┬──────┬───────────┬────────────────╮
│ # │                   name                    │ type │   size    │    modified    │
├───┼───────────────────────────────────────────┼──────┼───────────┼────────────────┤
│ 0 │ core-image-minimal-paulmann-signed.mender │ file │ 232,2 MiB │ 20 minutes ago │
│ 1 │ core-image-minimal-paulmann.mender        │ file │ 232,2 MiB │ 20 minutes ago │
│ 2 │ core-image-minimal-paulmann.sdimg         │ file │ 457,4 MiB │ 20 minutes ago │
│ 3 │ sha256sums.txt                            │ file │     544 B │ 56 years ago   │
│ 4 │ u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 20 minutes ago │
│ 5 │ uuu.auto                                  │ file │     509 B │ 20 minutes ago │
│ 6 │ uuu.exe                                   │ file │   1,2 MiB │ 20 minutes ago │
╰───┴───────────────────────────────────────────┴──────┴───────────┴────────────────╯
~/Downloads/test> sha256sum -c sha256sums.txt
core-image-minimal-paulmann-signed.mender: OK
core-image-minimal-paulmann.mender: OK
core-image-minimal-paulmann.sdimg: FEHLSCHLAG
u-boot-paulmann.imx: OK
uuu.auto: OK
uuu.exe: OK
sha256sum: WARNING: 1 computed checksum did NOT match
~/Downloads/test> cd ..
~/Downloads> mkdir test2
~/Downloads> file -i test.tar.bz2
test.tar.bz2: application/x-bzip2; charset=binary
~/Downloads> tar xf test.tar.bz2 -C test2/
~/Downloads> cd test2/
~/Downloads/test2> sha256sum -c sha256sums.txt
core-image-minimal-paulmann-signed.mender: OK
core-image-minimal-paulmann.mender: OK
core-image-minimal-paulmann.sdimg: OK
u-boot-paulmann.imx: OK
uuu.auto: OK
uuu.exe: OK
~/Downloads/test2> ls
╭───┬───────────────────────────────────────────┬──────┬───────────┬────────────────╮
│ # │                   name                    │ type │   size    │    modified    │
├───┼───────────────────────────────────────────┼──────┼───────────┼────────────────┤
│ 0 │ core-image-minimal-paulmann-signed.mender │ file │ 232,2 MiB │ 22 minutes ago │
│ 1 │ core-image-minimal-paulmann.mender        │ file │ 232,2 MiB │ 22 minutes ago │
│ 2 │ core-image-minimal-paulmann.sdimg         │ file │   6,5 GiB │ 22 minutes ago │
│ 3 │ sha256sums.txt                            │ file │     544 B │ 56 years ago   │
│ 4 │ u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 22 minutes ago │
│ 5 │ uuu.auto                                  │ file │     509 B │ 22 minutes ago │
│ 6 │ uuu.exe                                   │ file │   1,2 MiB │ 22 minutes ago │
╰───┴───────────────────────────────────────────┴──────┴───────────┴────────────────╯
~/Downloads/test2>                                                                                                                                        2026-07-28T12:26:00

The weird thing is, that all files, except the sdimg file are extracted correctly when I use the GUI extraction method.
You can also see, that the file sizes significantly differ.

Edit:
The extraction via file-roller extracts the archive correctly without issues.

Last edited by schard (2026-07-29 11:36:13)

cryptearth · 2026-07-28 12:00:05

sanity check: have you tried to first just decompress? so make a .tar from the .tar.bz2? the different filesizes hint tge decompression goes wrong prematurly

seth · 2026-07-28 14:08:14

I'd appreciate any pointers as to what might be the issue here.

/usr/lib/gvfsd-archive ?

Edit: I suspect the immediate problem will be the sdimg structure (is it compressed itself)?
file-roller seems to use libarchive as well, does bsdtar work correctly?

Last edited by seth (2026-07-28 14:41:33)

dimich · 2026-07-28 17:23:49

schard wrote:

│ 2 │ core-image-minimal-paulmann.sdimg │ file │ 457,4 MiB │ 20 minutes ago │
│ 2 │ core-image-minimal-paulmann.sdimg │ file │ 6,5 GiB │ 22 minutes ago │

Looks like 32-bit overflow bug (4 GiB limit). Can you create a 5 GiB file, compress it and decompress with nautilus?

schard · 2026-07-28 19:52:04

cryptearth wrote:

sanity check: have you tried to first just decompress? so make a .tar from the .tar.bz2? the different filesizes hint tge decompression goes wrong prematurly

First decompressing it, then extracting the plain .tar archive with nautilus results in the same too small file:

~/Downloads/310295> ls
╭───┬───────────────────────────────────────────┬──────┬───────────┬──────────────╮
│ # │                   name                    │ type │   size    │   modified   │
├───┼───────────────────────────────────────────┼──────┼───────────┼──────────────┤
│ 0 │ core-image-minimal-paulmann-signed.mender │ file │ 232,4 MiB │ 2 months ago │
│ 1 │ core-image-minimal-paulmann.mender        │ file │ 232,4 MiB │ 2 months ago │
│ 2 │ core-image-minimal-paulmann.sdimg         │ file │ 457,5 MiB │ 2 months ago │
│ 3 │ u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 2 months ago │
│ 4 │ uuu.auto                                  │ file │     509 B │ 2 months ago │
│ 5 │ uuu.exe                                   │ file │   1,2 MiB │ 2 months ago │
╰───┴───────────────────────────────────────────┴──────┴───────────┴──────────────╯
~/Downloads/310295>

It, however, works again when unpacking from the console:

~/Downloads> mkdir test2
~/Downloads> tar xf 310295.tar -C test2/
~/Downloads> cd test2/
~/Downloads/test2> ls
╭───┬───────────────────────────────────────────┬──────┬───────────┬──────────────╮
│ # │                   name                    │ type │   size    │   modified   │
├───┼───────────────────────────────────────────┼──────┼───────────┼──────────────┤
│ 0 │ core-image-minimal-paulmann-signed.mender │ file │ 232,4 MiB │ 2 months ago │
│ 1 │ core-image-minimal-paulmann.mender        │ file │ 232,4 MiB │ 2 months ago │
│ 2 │ core-image-minimal-paulmann.sdimg         │ file │   6,5 GiB │ 2 months ago │
│ 3 │ u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 2 months ago │
│ 4 │ uuu.auto                                  │ file │     509 B │ 2 months ago │
│ 5 │ uuu.exe                                   │ file │   1,2 MiB │ 2 months ago │
╰───┴───────────────────────────────────────────┴──────┴───────────┴──────────────╯
~/Downloads/test2>

seth wrote:

Edit: I suspect the immediate problem will be the sdimg structure (is it compressed itself)?
file-roller seems to use libarchive as well, does bsdtar work correctly?

Yes.

~/Downloads> bsdtar xf 310295.tar -C test3/
~/Downloads> cd test3/
~/Downloads/test3> ls
╭───┬───────────────────────────────────────────┬──────┬───────────┬──────────────╮
│ # │                   name                    │ type │   size    │   modified   │
├───┼───────────────────────────────────────────┼──────┼───────────┼──────────────┤
│ 0 │ core-image-minimal-paulmann-signed.mender │ file │ 232,4 MiB │ 2 months ago │
│ 1 │ core-image-minimal-paulmann.mender        │ file │ 232,4 MiB │ 2 months ago │
│ 2 │ core-image-minimal-paulmann.sdimg         │ file │   6,5 GiB │ 2 months ago │
│ 3 │ u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 2 months ago │
│ 4 │ uuu.auto                                  │ file │     509 B │ 2 months ago │
│ 5 │ uuu.exe                                   │ file │   1,2 MiB │ 2 months ago │
╰───┴───────────────────────────────────────────┴──────┴───────────┴──────────────╯
~/Downloads/test3>

dimich wrote:

schard wrote:
│ 2 │ core-image-minimal-paulmann.sdimg │ file │ 457,4 MiB │ 20 minutes ago │
│ 2 │ core-image-minimal-paulmann.sdimg │ file │ 6,5 GiB │ 22 minutes ago │
Looks like 32-bit overflow bug (4 GiB limit). Can you create a 5 GiB file, compress it and decompress with nautilus?

The dd-generated, archived, file extracts fine with nautilus:

~> dd if=/dev/urandom of=large_file bs=1M count=5120
~> tar --use-compress-program="bzip2 -9" -cf test.tar.bz2 large_file
~> file -i test.tar.bz2
test.tar.bz2: application/x-bzip2; charset=binary
~> tar --list -vf test.tar.bz2
-rw-r--r-- rne/rne  5368709120 2026-07-28 21:20 large_file
~> sha256sum large_file test/large_file
1a8c44017fd4067443aad71d2e50abcdb3edfb567afe49b74adbf937519eff5d  large_file
1a8c44017fd4067443aad71d2e50abcdb3edfb567afe49b74adbf937519eff5d  test/large_file
~> sha256sum large_file test/large_file

seth · 2026-07-28 19:58:39

So not libarchive nor a 4GB limit… have you tried to kill gvfsd and run it from an interactive shell to see whether it yells errors at you?
Not sure whether /usr/lib/gvfsd-archive can be used directly to mount the archive.

schard · 2026-07-28 20:07:17

Just for the fun of it, I used bsdtar to extract the archive, then tar with xz to pack it again.
This time, nautilus was able to extract it correctly:

~/Downloads> mkdir bsdtar.d
~/Downloads> bsdtar xf 310295.tar.bz2 -C bsdtar.d/
~/Downloads> cd bsdtar.d/
~/Downloads/bsdtar.d> ls
╭───┬───────────────────────────────────────────┬──────┬───────────┬──────────────╮
│ # │                   name                    │ type │   size    │   modified   │
├───┼───────────────────────────────────────────┼──────┼───────────┼──────────────┤
│ 0 │ core-image-minimal-paulmann-signed.mender │ file │ 232,4 MiB │ 2 months ago │
│ 1 │ core-image-minimal-paulmann.mender        │ file │ 232,4 MiB │ 2 months ago │
│ 2 │ core-image-minimal-paulmann.sdimg         │ file │   6,5 GiB │ 2 months ago │
│ 3 │ u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 2 months ago │
│ 4 │ uuu.auto                                  │ file │     509 B │ 2 months ago │
│ 5 │ uuu.exe                                   │ file │   1,2 MiB │ 2 months ago │
╰───┴───────────────────────────────────────────┴──────┴───────────┴──────────────╯
~/Downloads/bsdtar.d> tar cJf ../310295.tar.xz *
~/Downloads/bsdtar.d| ls 3                                                                                                                                                       28.07.2026 22:04:39
~/Downloads/bsdtar.d> cd ..
~/Downloads> ls 310295/
╭───┬──────────────────────────────────────────────────┬──────┬───────────┬──────────────╮
│ # │                       name                       │ type │   size    │   modified   │
├───┼──────────────────────────────────────────────────┼──────┼───────────┼──────────────┤
│ 0 │ 310295/core-image-minimal-paulmann-signed.mender │ file │ 232,4 MiB │ 2 months ago │
│ 1 │ 310295/core-image-minimal-paulmann.mender        │ file │ 232,4 MiB │ 2 months ago │
│ 2 │ 310295/core-image-minimal-paulmann.sdimg         │ file │   6,5 GiB │ 2 months ago │
│ 3 │ 310295/u-boot-paulmann.imx                       │ file │ 567,0 KiB │ 2 months ago │
│ 4 │ 310295/uuu.auto                                  │ file │     509 B │ 2 months ago │
│ 5 │ 310295/uuu.exe                                   │ file │   1,2 MiB │ 2 months ago │
╰───┴──────────────────────────────────────────────────┴──────┴───────────┴──────────────╯

Also with bz2 the re-packed archive can be extracted by nautilus:

~/Downloads> tar -tvf 310295.tar.bz2
-rw-r--r-- 1000/1000 243711488 2026-06-03 15:26 core-image-minimal-paulmann.mender
-rw------- 1000/1000 243712512 2026-06-03 15:26 core-image-minimal-paulmann-signed.mender
-rw-r--r-- 1000/1000    580608 2026-06-03 15:26 u-boot-paulmann.imx
-rw-r--r-- 1000/1000 6987710464 2026-06-03 15:26 core-image-minimal-paulmann.sdimg
-rw-r--r-- 1000/1000        509 2026-06-03 15:26 uuu.auto
-rw-r--r-- 1000/1000    1344000 2026-06-03 15:26 uuu.exe
~/Downloads> tar -tvf 310295_3.tar.bz2
-rw------- rne/rne   243712512 2026-06-03 15:26 core-image-minimal-paulmann-signed.mender
-rw-r--r-- rne/rne   243711488 2026-06-03 15:26 core-image-minimal-paulmann.mender
-rw-r--r-- rne/rne  6987710464 2026-06-03 15:26 core-image-minimal-paulmann.sdimg
-rw-r--r-- rne/rne      580608 2026-06-03 15:26 u-boot-paulmann.imx
-rw-r--r-- rne/rne         509 2026-06-03 15:26 uuu.auto
-rw-r--r-- rne/rne     1344000 2026-06-03 15:26 uuu.exe
~/Downloads> ls

seth · 2026-07-28 20:13:36

So… what created the original tarball (it cannot be the compression because of crypthearth's test?)
Does the (uncompressed) tarball differ from the previous one?

schard · 2026-07-28 20:20:37

Nope, but the order of their contents differ, so...

~/Downloads> sha256sum 310295_orig.tar 310295_3.tar
1d1d5ea078b98121042d246644af89034e1de9d1b8c8d7f436c77b178b056bcd  310295_orig.tar
1a6eb3510cb84c308f7a21a817bf5cfee069b474883768f949a7ebf35dd0a347  310295_3.tar
~/Downloads>
~/Downloads> tar -tvf 310295_orig.tar
-rw-r--r-- 1000/1000 243711488 2026-06-03 15:26 core-image-minimal-paulmann.mender
-rw------- 1000/1000 243712512 2026-06-03 15:26 core-image-minimal-paulmann-signed.mender
-rw-r--r-- 1000/1000    580608 2026-06-03 15:26 u-boot-paulmann.imx
-rw-r--r-- 1000/1000 6987710464 2026-06-03 15:26 core-image-minimal-paulmann.sdimg
-rw-r--r-- 1000/1000        509 2026-06-03 15:26 uuu.auto
-rw-r--r-- 1000/1000    1344000 2026-06-03 15:26 uuu.exe
~/Downloads> tar -tvf 310295_3.tar
-rw------- rne/rne   243712512 2026-06-03 15:26 core-image-minimal-paulmann-signed.mender
-rw-r--r-- rne/rne   243711488 2026-06-03 15:26 core-image-minimal-paulmann.mender
-rw-r--r-- rne/rne  6987710464 2026-06-03 15:26 core-image-minimal-paulmann.sdimg
-rw-r--r-- rne/rne      580608 2026-06-03 15:26 u-boot-paulmann.imx
-rw-r--r-- rne/rne         509 2026-06-03 15:26 uuu.auto
-rw-r--r-- rne/rne     1344000 2026-06-03 15:26 uuu.exe
~/Downloads>                                                                                                                                                                     28.07.2026 22:20:16

seth · 2026-07-28 20:27:28

I assume recreating the original order breaks it again?
Is the problem that u-boot-paulmann.imx is ahead or that uuu.auto is right after it?

schard · 2026-07-28 20:39:24

No, it doesn't. Which may hint to a problem in the original archive.
A recreated archive with the same order extracts fine with nautilus.
It was created by a Rust program using tar¹ and bzip2². :-\
I'll see if I can whip up an MRE tomorrow.

[1] https://crates.io/crates/tar
[2] https://crates.io/crates/bzip2

schard · 2026-07-29 11:35:31

Solution

It *is* a bug in nautilus' tar handling!

~/Downloads/sparsetest> truncate -s 6656M sparse.img
~/Downloads/sparsetest> ls
╭───┬────────────┬──────┬─────────┬──────────╮
│ # │    name    │ type │  size   │ modified │
├───┼────────────┼──────┼─────────┼──────────┤
│ 0 │ sparse.img │ file │ 6,5 GiB │ now      │
╰───┴────────────┴──────┴─────────┴──────────╯
~/Downloads/sparsetest> tar cf sparse.tar sparse.img
~/Downloads/sparsetest> ls
╭───┬────────────┬──────┬─────────┬────────────────╮
│ # │    name    │ type │  size   │    modified    │
├───┼────────────┼──────┼─────────┼────────────────┤
│ 0 │ sparse.img │ file │ 6,5 GiB │ 29 seconds ago │
│ 1 │ sparse.tar │ file │ 6,5 GiB │ now            │
╰───┴────────────┴──────┴─────────┴────────────────╯
~/Downloads/sparsetest> rm sparse.tar
~/Downloads/sparsetest> tar --sparse -cf archive.tar sparse.img
~/Downloads/sparsetest> ls
╭───┬─────────────┬──────┬──────────┬──────────────╮
│ # │    name     │ type │   size   │   modified   │
├───┼─────────────┼──────┼──────────┼──────────────┤
│ 0 │ archive.tar │ file │ 10,0 KiB │ now          │
│ 1 │ sparse.img  │ file │  6,5 GiB │ a minute ago │
╰───┴─────────────┴──────┴──────────┴──────────────╯
~/Downloads/sparsetest> ls
╭───┬─────────────┬──────┬──────────┬────────────────╮
│ # │    name     │ type │   size   │    modified    │
├───┼─────────────┼──────┼──────────┼────────────────┤
│ 0 │ archive     │ dir  │  4,0 KiB │ now            │
│ 1 │ archive.tar │ file │ 10,0 KiB │ 18 seconds ago │
│ 2 │ sparse.img  │ file │  6,5 GiB │ a minute ago   │
╰───┴─────────────┴──────┴──────────┴────────────────╯
~/Downloads/sparsetest> ls archive/
╭───┬────────────────────┬──────┬──────┬──────────────╮
│ # │        name        │ type │ size │   modified   │
├───┼────────────────────┼──────┼──────┼──────────────┤
│ 0 │ archive/sparse.img │ file │  0 B │ a minute ago │
╰───┴────────────────────┴──────┴──────┴──────────────╯
~/Downloads/sparsetest> tree

The file is a sparse file and nautilus cannot extract those correctly.

seth · 2026-07-29 13:56:06

https://gitlab.gnome.org/GNOME/gvfs/-/work_items
Maybe protection against zip bombs?

schard · 2026-07-30 09:21:59

FYI: This is broken since five years: https://gitlab.gnome.org/GNOME/gnome-au … rk_items/9

seth · 2026-07-30 11:59:42

So there's gvfs-archive wrapping libarchive but only gnome-shell, nautilus and evolution are not using that but a gsoc2013 project that also wraps libarchive and that has a major bug, filed by the maintainer along details on ow to fix it (instead of, ya know… fixing it) but remains unaddressed since 2021… and the project itself seems dormant since 2024
Though to be fair, the bug was probably just lifted from gvfsd-archive, https://gitlab.gnome.org/GNOME/gvfs/-/b … ive.c#L386 (by the same author)

Have you considered to just use midnight commander?

schard · 2026-07-30 20:43:23

I'll just use tar now that I know of that bug.
I even implemented a fix for that bug, but since its partially generated by Codex and the Gnome folks fundamentally refuse AI generated code, I didn't even attempt to submit it.

cryptearth · 2026-07-30 21:50:11

well, unless there is already you should at least open an issue to let them know and figure out a fix n thier own
i would add that you tave a working solution for your case and would provide it as input if they accept it was ai generated
just stick your head in the sand with "i got it working for me" is not how the foss community works - no matter if someone dislikes how you came up with your solution

dimich · 2026-07-30 22:00:15

This patch seems fixes the issue:

diff --git a/gnome-autoar/autoar-extractor.c b/gnome-autoar/autoar-extractor.c
index 775223c..ee57145 100644
--- a/gnome-autoar/autoar-extractor.c
+++ b/gnome-autoar/autoar-extractor.c
@@ -1126,7 +1126,7 @@ autoar_extractor_do_write_entry (AutoarExtractor      *self,
         GOutputStream *ostream;
         const void *buffer;
         size_t size, written;
-        gint64 offset;
+        la_int64_t offset;
 
         g_debug ("autoar_extractor_do_write_entry: case REG");
 
@@ -1142,12 +1142,34 @@ autoar_extractor_do_write_entry (AutoarExtractor      *self,
         if (ostream != NULL) {
           /* Archive entry size may be zero if we use raw format. */
           if (archive_entry_size(entry) > 0 || self->use_raw_format) {
+
+            // TODO: make ensure G_IS_SEEKABLE(ostream) and abort if it is not
+
             while ((r = archive_read_data_block (a, &buffer, &size, &offset)) == ARCHIVE_OK) {
               /* buffer == NULL occurs in some zip archives when an entry is
                * completely read. We just skip this situation to prevent GIO
                * warnings. */
               if (buffer == NULL)
                 continue;
+
+              g_seekable_seek (G_SEEKABLE(ostream),
+                               offset,
+                               G_SEEK_SET,
+                               self->cancellable,
+                               &self->error);
+              if (self->error != NULL) {
+                g_output_stream_close (ostream, self->cancellable, NULL);
+                g_object_unref (ostream);
+                g_object_unref (info);
+                return;
+              }
+              if (g_cancellable_is_cancelled (self->cancellable)) {
+                g_output_stream_close (ostream, self->cancellable, NULL);
+                g_object_unref (ostream);
+                g_object_unref (info);
+                return;
+              }
+
               g_output_stream_write_all (ostream,
                                          buffer,
                                          size,

Generated by me. Tested very superficially.
Of course, this is not the only way to fix the bug and is not most optimal. (I could deduplicate repeated parts of code and rewrite half of that existing code, but that would be too much.)
But I'm too lazy to login into gitlab.gnome.org and prepare PR, especially since I don't use nautilus.

If upstream won't fix the bug, I think downstream package shoud do this.

UPD: the patch above incorrectly handles case when sparse area is at the end of file. Will try to update later.
Also it's not clear how they handle self->completed_size during extraction: should it be a sum of file sizes or total amount of actually extracted data. Logically it should be the former but who knows...

Last edited by dimich (Yesterday 05:11:30)

dimich · Yesterday 05:09:57

This variant of patch looks better. It keeps trailing gaps as well. Also updates completed_size according to output file size.

diff --git a/gnome-autoar/autoar-extractor.c b/gnome-autoar/autoar-extractor.c
index 775223c..2a7c8e0 100644
--- a/gnome-autoar/autoar-extractor.c
+++ b/gnome-autoar/autoar-extractor.c
@@ -1126,7 +1126,8 @@ autoar_extractor_do_write_entry (AutoarExtractor      *self,
         GOutputStream *ostream;
         const void *buffer;
         size_t size, written;
-        gint64 offset;
+        la_int64_t offset;
+        gint64 ostream_offset = 0;
 
         g_debug ("autoar_extractor_do_write_entry: case REG");
 
@@ -1148,6 +1149,29 @@ autoar_extractor_do_write_entry (AutoarExtractor      *self,
                * warnings. */
               if (buffer == NULL)
                 continue;
+
+              if (offset > ostream_offset) {
+                g_seekable_seek (G_SEEKABLE(ostream),
+                                 offset,
+                                 G_SEEK_SET,
+                                 self->cancellable,
+                                 &self->error);
+                if (self->error != NULL) {
+                  g_output_stream_close (ostream, self->cancellable, NULL);
+                  g_object_unref (ostream);
+                  g_object_unref (info);
+                  return;
+                }
+                if (g_cancellable_is_cancelled (self->cancellable)) {
+                  g_output_stream_close (ostream, self->cancellable, NULL);
+                  g_object_unref (ostream);
+                  g_object_unref (info);
+                  return;
+                }
+                self->completed_size += offset - ostream_offset;
+                ostream_offset = offset;
+              }
+
               g_output_stream_write_all (ostream,
                                          buffer,
                                          size,
@@ -1166,6 +1190,7 @@ autoar_extractor_do_write_entry (AutoarExtractor      *self,
                 g_object_unref (info);
                 return;
               }
+              ostream_offset += written;
               self->completed_size += written;
               autoar_extractor_signal_progress (self);
             }
@@ -1179,6 +1204,25 @@ autoar_extractor_do_write_entry (AutoarExtractor      *self,
 
               return;
             }
+
+            if (archive_entry_size(entry) > ostream_offset) {
+              g_seekable_truncate (G_SEEKABLE(ostream),
+                                   archive_entry_size(entry),
+                                   self->cancellable,
+                                   &self->error);
+              if (self->error != NULL) {
+                g_output_stream_close (ostream, self->cancellable, NULL);
+                g_object_unref (ostream);
+                g_object_unref (info);
+                return;
+              }
+              if (g_cancellable_is_cancelled (self->cancellable)) {
+                g_output_stream_close (ostream, self->cancellable, NULL);
+                g_object_unref (ostream);
+                g_object_unref (info);
+                return;
+              }
+            }
           }
           g_output_stream_close (ostream, self->cancellable, NULL);
           g_object_unref (ostream);

seth · Yesterday 06:33:36

@cryptearh, there is an open bug, filed 5 years ago by the maintainer himself, including an explanation how to actually fix it.
Over the years multiple duplicates have been tagged and, without diminishing @dimich's efforts (not tested but superficially looks reasonable enough), it's not that complicated to fix either.

Conclude from that what you will, randomly stumbled over https://gitlab.gnome.org/GNOME/file-rol … _items/167

cryptearth · Yesterday 07:07:02

@seth
honestly didn't bothered to even look - i use dolphin with ark on kde - or konsole anyway
tried gnome once - just not my style (although i can see it fits well others')

Arch Linux

#1 2026-07-28 10:33:45

[SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#2 2026-07-28 12:00:05

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#3 2026-07-28 14:08:14

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#4 2026-07-28 17:23:49

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#5 2026-07-28 19:52:04

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#6 2026-07-28 19:58:39

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#7 2026-07-28 20:07:17

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#8 2026-07-28 20:13:36

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#9 2026-07-28 20:20:37

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#10 2026-07-28 20:27:28

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#11 2026-07-28 20:39:24

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#12 2026-07-29 11:35:31

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#13 2026-07-29 13:56:06

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#14 2026-07-30 09:21:59

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#15 2026-07-30 11:59:42

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#16 2026-07-30 20:43:23

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#17 2026-07-30 21:50:11

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#18 2026-07-30 22:00:15

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#19 Yesterday 05:09:57

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#20 Yesterday 06:33:36

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

#21 Yesterday 07:07:02

Re: [SOLVED] tar.bz2 content partially corrupted when extracted via GUI

Board footer