No output file from archiver with parted rar/7z archives over engrampa

[ltspicer]

My system:
Linux Mint 17.3 Rosa 64-bit
Kernel Linux 3.19.0-32-generic x86_64
MATE 1.12.0

Packing over the terminal works fine.
With engrampa (right mouse button), it works only with not parted archives (single file).
If i want to create a parted archive over engrampa, the process works and create a temp folder with the compressed output files.
After processing, the created temp folder will be deleted.
That's so since 17.1. With 17.0 it works correctly.

[ltspicer]

No other people have this problem?
In LMDE2 and LM18 is the same :(
If i install engrampa_1.8.0-0 (standard version in LM 17.0), it works.

[ltspicer]

PUSH
Still the same bug. Also in Mint Sarah.
If i install the old packages from Qiana
engrampa-common_1.8.0-0+qiana_all.deb
and
engrampa_1.8.0-0+qiana_amd64.deb
it work.

[ltspicer]

Ok. Wenn Du keine Zeit oder Lust hast, dann gib mir den Code.
Ich werde das in Ordnung bringen.
Es kann ja nicht sein, dass dieses kleine Tool eine ganze Linuxgemeinde in Verlegenheit bringt!

[raveit65]

Bitte, https://github.com/mate-desktop/engrampa

[ltspicer]

Das Qiana Paket muss doch in die Quellen! Es kann nicht sein, dass eine Neuinstallation von LM Mate den fehler integriert hat!
https://bugs.launchpad.net/linuxmint/+bug/1653190
http://www.linuxmintusers.de/index.php?topic=31765.msg551063#msg551063 Antwort #32

[voger]

I have the same problem. Manjaro Linux with Xfce and engrampa 1.16.0

[sc0w]

@treki1 in english, please

That's so since 17.1. With 17.0 it works correctly.

engrampa version that works?

[ltspicer]

The old packages from Qiana (lm17)
engrampa-common_1.8.0-0+qiana_all.deb
and
engrampa_1.8.0-0+qiana_amd64.deb
work with lm17.1 - lm18.1
@sc0w: Thank you for taking care of it ^^

[sc0w]

I can reproduce it on engrampa 1.10.1, and works on 1.8.1

[ltspicer]

I not understand :(
What you do reproduce? And it work? You have rar parts?

[sc0w]

I mean: engrampa 1.10.1 have same problem, and it works on 1.8.1

[ltspicer]

Is 1.8.1 the same like 1.8.0 in the qiana package?

[sc0w]

no, 1.8.1 is 1.8.0 with a little few changes

I found the guilty commit: 0b3b7ee

[sc0w]

The part files are successfully extracted to the temp folder, but engrampa can't move them to the destination folder

[ltspicer]

Yes. I know. Do you know why?

[sc0w]

because after 0b3b7ee the code only moves one compressed file.

https://github.com/mate-desktop/engrampa/blob/master/src/fr-archive.c#L1749

for example, for 7z files:

the bug: engrampa moves one unique .7z file always

the expected: engrampa must to move the files .7z.001 .7z.002 ... ... with parted files

[sc0w]

fr_process_add_arg_concat (archive->process, tmp_archive_filename, "001", NULL);
fr_process_add_arg (archive->process, tmp_base_dir);

it works for the first file, but with:

fr_process_add_arg_concat (archive->process, tmp_archive_filename, "*", NULL);
fr_process_add_arg (archive->process, tmp_base_dir);

it doesn't work, it seems the char * is escaped, the wildcards don't works

and, at this point, I can't check the existence of the file with

if (g_file_test(tmp_archive_filename, G_FILE_TEST_EXISTS))

because the file is not created yet

[sc0w]

seems the chars are escaped by g_spawn_async_with_pipes

https://github.com/mate-desktop/engrampa/blob/master/src/fr-process.c#L708

[ltspicer]

Thx sc0w so much.
Now it can flow in in future versions of mate-desktop.
I see this bug at beginning of 2016. No one believed me first ^^

[sc0w]

thanks to you for report the issue

[ltspicer]

I work sometimes for the w****z scene.
This must have the old RAR system & exactly 100000000 Byte per part.
Is possible to implement in the GUI of engrampa, which allows to select options like:
rar a -vn -v100000000f -m0 -rr1 $name2.rar *.mkv
The new RAR-system is not allowed there.
Perfect are: When i can select divers settings for packing.
Thx

PS:
@sc0w: I'm jealous. What great (genius) programmer are you? OO