mate-desktop / engrampa Goto Github PK

Using unar, on the rar file, is a file or directory compressed with the
character [ on the name, engrampa don't works.

With only command unar in console without engrampa, works perfectly.

----- extracting with [ on directory's name:

: Uncaught exception XADRegexException, reason: Could not compile regex
"^te[sting/errorengrampa$": Unmatched [ or [^

te[sting is the directory

----- extracting with [ ] on directory's name:

don't show error, but can not extract it.

te[st]ing is the directory

----- extracting with [ on file's name:

: Uncaught exception XADRegexException, reason: Could not compile regex
"^3645494/testing/te[sting.test$": Unmatched [ or [^

te[sting.test is the file

----- extractubg with [ ] on file's name:

mv: cannot stat ‘/home/scow/.aMule/Incoming/TTTtestear
engrampa/.fr-5DdpMt/3645494/testing/te[st]ing.test’: No such file or
directory

te[st]ing.test is the file

On directory or file, with ] on name without [ engrampa works perfectly.

On caja, if I "right click" on rar file, and I click on "extract here",
works perfectly.

The problem is while I drag and drop files/directories from engrampa to
caja.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766998

thanks

no-manual-page-for-binary engrampa
Each executable in standard binary directories should have a man page.

Engrampa uses p7zip as backend but why not be able to read UDF ISO, I would like Engrampa can read and extract UDF ISO. P7zip is able to extract UDF ISO, RAR5, ESD archives, ext2, ext3, ext4 and many more.

I noticed engrampa showing an error when passing files to tar which contain some backslashes.

Example:
user@pc:$ touch '\'
user@pc:$ engrampa --add-to=test.tar '\'

or
user@pc:$ touch \\
user@pc:$ engrampa --add-to=test.tar \\

Output:

An error occurred while adding files to the archive.

Command Line Output
tar: \: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors

But:
user@pc:$ touch \
user@pc:$ engrampa --add-to=test.tar \
works.

Best regards

would be nice to be able to set a default file extension used for archiving files in the gui and also be able to have a commandline argument for setting the archive extension when using the '--add' argument.

As stated the files when extracted should not be extracted to another directory rather than the output directory. When extracting a 7z file or zip or whatever else it creates a directory in the cache directory and then extracts it there instead of passing the output directory to the extraction process itself.

I forgot to say that you're copying not only the file itself but also the source archive. I don't know why in the world you're doing this as it's not that hard to simply grab the source directory of the file and then pass that as the source directory for the archive, and then list the files that way. And then the extraction can easily be set by using the -c command for xz/gzip and others that don't really do output directories. That could be easily done and all you're doing is wasting cpu time, and causing needless writes on ssds/hard drives. I can't believe that that old bug from file-roller is still there in this thing.

If you create an archive that contains a symlink,
this archive will not be extractable by engrampa
if the symlink is a link to itself, its parent directory
or any ancestor.

Engrampa should not follow symlinks whose
real path is itself an ancestor's real path.
Additional engrampa should not exclude
broken symlinks.

Note that engrampa is able to create archives
containing symlinks like this, but it is not able
to extract them.

I: engrampa: desktop-entry-lacks-keywords-entry usr/share/applications/engrampa.desktop
N:
N: This .desktop file does either not contain a "Keywords" entry or it does
N: not contain any keywords not already present in the "Name" or
N: "GenericName" entries.
N:
N: .desktop files are organized in key/value pairs (similar to .ini files).
N: "Keywords" is the name of the entry/key in the .desktop file containing
N: keywords relevant for this .desktop file.
N:
N: The desktop-file-validate tool in the desktop-file-utils package is
N: useful for checking the syntax of desktop entries.
N:
N: Refer to
N: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html,
N: http://bugs.debian.org/693918, and
N: https://wiki.gnome.org/Initiatives/GnomeGoals/DesktopFileKeywords for
N: details.
N:
N: Severity: wishlist, Certainty: certain
N:
N: Check: menu-format, Type: binary
N:

i opened up a .tar.gz file, which had a .deb file in it and right-click 'open' will load up gdebi which i dont want as i want to open up the .deb file as an archive in engrampa, so i went for 'open with...' only to realize that after i select an entry in the 'open with' dialog, it will make it the permanent open option there after, which i dont want as then i'd have to change the behaviour back.

With unrar version 5.x, the formatting of the output has changed considerably, compared to version 4.x and engrampa fails to decompress rar archives.

Here is an example output of "unrar v -c- -v" with unrar 5:

UNRAR 5.00 freeware      Copyright (c) 1993-2013 Alexander Roshal

Archive: PDVET1andT2.rar
Details: RAR 4

 Attributes      Size    Packed Ratio   Date   Time   Checksum  Name
----------- ---------  -------- ----- -------- -----  --------  ----
    ..A....    134319    124780  92%  10-07-13 11:23  B800A928  PDVET1andT2.pdf
----------- ---------  -------- ----- -------- -----  --------  ----
               134319    124780  92%                            1

and with unrar 4.20:

UNRAR 4.20 freeware      Copyright (c) 1993-2012 Alexander Roshal

Archive PDVET1andT2.rar

Pathname/Comment
                  Size   Packed Ratio  Date   Time     Attr      CRC   Meth Ver
-------------------------------------------------------------------------------
 PDVET1andT2.pdf
                134319   124780  92% 10-07-13 11:23  .....A.   B800A928 m3c 2.9
-------------------------------------------------------------------------------
    1           134319   124780  92%

http://git.gnome.org/browse/file-roller/tree/src/fr-command-unarchiver.c
http://git.gnome.org/browse/file-roller/tree/src/fr-command-unarchiver.h

unarchiver is currently the only free software (in RMS sense) that can extract RAR archives. It also support many other archive types and has built-in encoding detection / conversion feature.

http://code.google.com/p/theunarchiver/
http://www.fsf.org/blogs/licensing/free-rarv3-extraction

Debian / Ubuntu package for it is "unar".

Build with directory fix:

[rave@mother ~]$ engrampa

(engrampa:28914): Gtk-WARNING **: Error loading theme icon 'extract-archive' for stock: Symbol »extract-archive« nicht im Thema vorhanden

(engrampa:28914): Gtk-WARNING **: Error loading theme icon 'add-files-to-archive' for stock: Symbol »add-files-to-archive« nicht im Thema vorhanden

(engrampa:28914): Gtk-WARNING **: Error loading theme icon 'add-folder-to-archive' for stock: Symbol »add-folder-to-archive« nicht im Thema vorhanden

Those icons are in
/usr/share/engrampa/icons/hicolor/...../actions/...

Add "libarchive/bsdtar" and "The Unarchiver/unar" support for (rar and others)
files support

bsdtar and unar support rar v3[0][1]

[0]http://libarchive.org
[1]http://unarchiver.c3.cx/formats

Names of files on Cyrillics aren't correctly displayed in zip archives. In ubuntu without mate (14.04, 14.10) file-roller displays them correctly. For example this zip-archive - http://1drv.ms/11Sq7Om . Ubuntu - mate 14.10.
Here picture of this bug - http://1drv.ms/11Ssd0z

The man page has a new typo...
http://anonscm.debian.org/cgit/pkg-mate/engrampa.git/diff/debian/patches/1001_typo-in-man-page.patch?id=9159fe0d28729fa3e9376e65d2befc15230ce03d

7z and also versions of unzip older than 6.10b, don't support utf8 properly. Zip archives created on windows that have files with non-latin filenames show up as garbage.

Here's a sample zip archive that displays this problem:
http://pnboy.pinguix.com/gapan/23-10-2012-b-fasi-eaep.zip

Same problem is with cbz files, which are actually zip files.

Removing/commenting out lines 527 and 530 from src/fr-command-7z.c fixes this and opens zip files with unzip, but it removes the mimetypes from 7z completely.

Ideally, priority should be given to unzip first and if unzip is not present, fall back to 7z, if 7z is installed.

incorrect-fsf-address

Engrampa use wrong installation path and kill rpm archives support.

/usr/libexec/mate-file-archiver/isoinfo.sh
/usr/libexec/mate-file-archiver/rpm2cpio
/usr/share/mate-file-archiver/icons/hicolor/16x16/actions/add-files-to-archive.png
/usr/share/mate-file-archiver/icons/hicolor/16x16/actions/add-folder-to-archive.png
/usr/share/mate-file-archiver/icons/hicolor/16x16/actions/extract-archive.png
/usr/share/mate-file-archiver/icons/hicolor/24x24/actions/add-files-to-archive.png
/usr/share/mate-file-archiver/icons/hicolor/24x24/actions/add-folder-to-archive.png
/usr/share/mate-file-archiver/icons/hicolor/24x24/actions/extract-archive.png

In result opening a rpm failed.

Old working directories with 1.6.0 were

/usr/libexec/engrampa/isoinfo.sh
/usr/libexec/engrampa/rpm2cpio
/usr/share/engrampa/icons/hicolor/16x16/actions/add-files-to-archive.png
/usr/share/engrampa/icons/hicolor/16x16/actions/add-folder-to-archive.png
/usr/share/engrampa/icons/hicolor/16x16/actions/extract-archive.png
/usr/share/engrampa/icons/hicolor/24x24/actions/add-files-to-archive.png
/usr/share/engrampa/icons/hicolor/24x24/actions/add-folder-to-archive.png
/usr/share/engrampa/icons/hicolor/24x24/actions/extract-archive.png

i extracted an archive file which had directory links to other folders, and when i tried to create an archive file from the same files i extracted, it followed the directory links and pulled in all files and directories underneath it. i would like to request that an option be added to the archive creation dialog under 'other options' of not following symbolic links.

I had 18 zip files to decompress, I wanted to move the uncompressed folders to a sepreate directory.
when i ran the decompress to a specific location, only 1 of the 18 decompressed properly.

So then I tried highlighting all of the compressed packages, and chose "extract here". All the files and folders were promptly decompressed. so that works.

So then I tried it with 2 zipped packages. That extracted to a specified directory as expected.
Next I tired extracting 10 zipped packages to a directory spcified, and that failed. By fail, I mean the operation did not produce the expected output. There have been no message boxes or errors, or warnings that I have seen.

Then I tried decompressing 5 packages to a directory. That failed. Only the 5th package was extracted to the selected directory..

I want to note, my zip package names are php01 through php18
Im going to sleep now. Iam using debian 8 with mate 1.8

I'm using engrampa 1.4.0 on Arch Linux x86. If I try to open an rpm (like this one: ftp://ftp.ntua.gr/pub/linux/unity/repo/openmandriva/i586/media/contrib/release/mate-file-archiver-1.2.1-1-mdv2012.0.i586.rpm ) with engrampa, it tells me "Archive type not supported". I have rpmextract installed, which will extract it without problems. Please add support for extracting rpms from engrampa.

I have a compressed rar file, with some pdf files, and I can't manage them, and I can't extract from engrampha.
But the 7zip-FM manages them.

It happens with every .rar arhive I tried to open. GDB output gives this:

pabab@galadriel:/opt/engrampa$ gdb --args ./src/engrampa /home/pabab/Descargas/PROG2.rar 
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/engrampa...done.
(gdb) r
Starting program: /opt/engrampa/src/engrampa /home/pabab/Descargas/PROG2.rar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffef9a0700 (LWP 14527)]
[New Thread 0x7fffeef71700 (LWP 14528)]
[New Thread 0x7fffee405700 (LWP 14529)]

(engrampa:14523): GLib-CRITICAL **: g_strchomp: assertion 'string != NULL' failed

Program received signal SIGSEGV, Segmentation fault.
parse_name_field (line=<optimized out>, rar_comm=0x9ed720) at fr-command-rar.c:155
155     if (*name_field == '/') {
(gdb) 

It seems to be a file-roller related problem. I'm usin unrar-free:

pabab@galadriel:~$ unrar --version
unrar 0.0.1

Basically I'd like to have a right click entry to test the archive.
This is something that is present in 7zip on windows for example, but I've never found it on linux DE.

The behaviour is like this:

1. If the file is not damaged, it shows a window with "archive is inctat" or something.
2. If the file is damaged, it shows a window with the list of issues (directly from the cli maybe?)

The idea is not having to open the archive at all and check the integrity FAST.

When you try to open a password-protected .rar file with Engrampa that has had it's file list encrypted, the following error displays:

CRC failed in the encrypted file /path/to/file.rar. Corrupt file or wrong password.

The funny thing is that it doesn't even ask for the password first. Wheter you try to just open it or extract it directly, this shows up. It doesn't happen with .rar's with a non-encrypted file list.

I have tried this in Engrampa 1.2 and 1.4, with .rar files created with Engrampa and with other compressors. The behaviour is exactly the same.

I am running Linux Mint 13 64-bits with MATE 1.4

EDIT: I can confirm that this wasn't an issue with file-roller in GNOME 2.

I: engrampa: hyphen-used-as-minus-sign usr/share/man/man1/engrampa.1.gz:75
N:
N: This manual page seems to contain a hyphen where a minus sign was
N: intended. By default, "-" chars are interpreted as hyphens (U+2010) by
N: groff, not as minus signs (U+002D). Since options to programs use minus
N: signs (U+002D), this means for example in UTF-8 locales that you cannot
N: cut and paste options, nor search for them easily. The Debian groff
N: package currently forces "-" to be interpreted as a minus sign due to
N: the number of manual pages with this problem, but this is a
N: Debian-specific modification and hopefully eventually can be removed.
N:
N: "-" must be escaped ("-") to be interpreted as minus. If you really
N: intend a hyphen (normally you don't), write it as "(hy" to emphasise
N: that fact. See groff(7) and especially groff_char(7) for details, and
N: also the thread starting with
N: http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01481.html
N:
N: If you use some tool that converts your documentation to groff format,
N: this tag may indicate a bug in the tool. Some tools convert dashes of
N: any kind to hyphens. The safe way of converting dashes is to convert
N: them to "-".
N:
N: Because this error can occur very often, Lintian shows only the first 10
N: occurrences for each man page and give the number of suppressed
N: occurrences. If you want to see all warnings, run Lintian with the
N: -d/--debug option.
N:
N: Refer to /usr/share/doc/groff-base/README.Debian and the groff_char(7)
N: manual page for details.
N:
N: Severity: wishlist, Certainty: possible
N:
N: Check: manpages, Type: binary
N:

A function uses a 'return;' statement, but has actually a value
to return, like an integer ('return 42;') or similar.

voidreturn fr-window.c:6747, 6757

I've downloaded a source code tarball from Github.

Extracted with engrampa 1.8.0 on Mint 17: contains 6945 objects.
Extracted via command line: contains 6945 objects.

Compress that folder and extract it with engrampa: 6719 objects!
Did the same on command line: contains 6945 objects.

Orginal report at fedora bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=928984

Mike Zet 2013-03-28 18:47:11 EDT

Description of problem:
Opening rar archive by MATE Caja File Manager

Version-Release number of selected component:
mate-file-archiver-1.5.1-6.fc18

Additional info:
backtrace_rating: 4
cmdline: engrampa /home/michuzet/Pobrane/B0n1v3rF0r3mm4F0r3v3r4g0.rar
crash_function: egg_tree_multi_drag_button_release_event
executable: /usr/bin/engrampa
kernel: 3.8.4-202.fc18.x86_64
uid: 1000
ureports_counter: 1

Truncated backtrace:
Thread no. 1 (7 frames)
 #0 egg_tree_multi_drag_button_release_event at eggtreemultidnd.c:204
 #1 _gtk_marshal_BOOLEAN__BOXED at gtkmarshalers.c:86
 #6 gtk_widget_event_internal at gtkwidget.c:5017
 #7 gtk_widget_event at gtkwidget.c:4814
 #8 gtk_propagate_event at gtkmain.c:2490
 #9 gtk_main_do_event at gtkmain.c:1685
 #15 gtk_main at gtkmain.c:1257

backtrace:
https://bugzilla.redhat.com/attachment.cgi?id=717876
core_backtrace:
https://bugzilla.redhat.com/attachment.cgi?id=717878

glad08 2013-04-24 08:55:50 EDT

I try to open zip archive by double clicking from caja.

backtrace_rating: 4
cmdline: engrampa /home/titov/svn/development/gui/js/gwt/images.zip
crash_function: egg_tree_multi_drag_button_release_event
executable: /usr/bin/engrampa
kernel: 3.8.8-202.fc18.x86_64
package: mate-file-archiver-1.5.1-6.fc18
reason: Process /usr/bin/engrampa was killed by signal 11 (SIGSEGV)
uid: 1000
ureports_counter: 1

glad08 2013-07-16 10:03:20 EDT

I get this bug again when open archive which attached above and double click inside it on QR folder, after that engrampa crashes.

I could upload detailed info about crash from gnome-abrt history if somebody say me how (which files needed and where find it in my system).

backtrace glad08:
https://bugzilla.redhat.com/attachment.cgi?id=774649

glad08 2013-07-17 03:18:21 EDT

No, I use mate-file-archiver-1.6.0-2.fc18.x86_64 from fedora 18 repo. Is it not latest version? Should I install mate-file-archiver from testing repo?

I can open that archive both from mate-file-archiver and from caja by doubleclicking. I observe crash just one time - the first time, and not at the moment of doubleclicking on file, but at the moment I double click on folder inside archive when archive was already opened in mate-file-archiver.
The next attempts are all be successfull - program doesn't crash anymore. I don't know what it may be. Can only suggest it may be related to some action, which doing just once for each archive - some caching, generating previews or any such things like that.

Backtrace I attached above.

Hi,

see issue's subject and Debian bug 749951 [1]...

---------------------------------------------------------------

202,203c202
<   if (junk_paths)
<       fr_process_add_arg (comm->process, "-D");

---
>   fr_process_add_arg (comm->process, "-D");

----------------------------------------------------------------

Please evaluate the above patch and let me know if it is an appropriate solution.

Thanks,
Mike

[1] http://bugs.debian.org/749951

Do not extract to /.fr-XXXXXX.

Upon opening file(s) directly from Engrampa, extract to /tmp/eng-XXXXXX (Xarchiver style) or /tmp/engrampa.XXXXXX (Comix style).

i.e. no version, no copyright, no author...

Is there a reason why engrampa uses its own copy of rpm2cpio and not the one that could be installed through a distros package or ports manager?

I downloaded thunderbird twice, opening with engrampa. The second time, engrampa was not able to open the package, since its name was thunderbird-38.1.0.tar-1.bz2 (note the -1).

User lah7 reports this issue on Launchpad:
https://bugs.launchpad.net/ubuntu-mate/+bug/1467318

I couldn't find where Engrampa has implemented this and if it hasn't, am submitting it as a feature request, and if not, a bug.

Engrampa uses p7zip as backend but why not be able to read UDF ISO, I would like Engrampa can read and extract UDF ISO. P7zip is able to extract UDF ISO, RAR5, ESD archives, ext2, ext3, ext4 and many more.

Hi Sander,

there is a discrepancy in the commit messages on the 1.8 branch and the tag for the latest 1.8.x release.

Git history on 1.8 branch alludes, that the last release was 1.8.1...

However, 1.8.2 is the latest tag for the 1.8.x series, no tag for 1.8.1 can be found.

I want to get engrampa 1.8.1 into Debian today, so please fix the tagging ASAP.

Thanks,
Mike

Documenting that this problem exists. I Traced this behaviour back to the 1.8 release @ commit da051c2. Initially I thought I broke something but unfortunately not..

File roller 3.12 does not have this problem so hopefully it is something fixed in FR we can pull into engrampa.

A CLI-invoked tar will store all symlinks as symlinks in the archive. For symlinks to directories this means that the contents of the linked-to directory are NOT included.
Extracting such an archive will create an exact copy of the original directories/files structure - the symlinks are still symlinks.

When creating an archive engrampa/file-roller follows directory symlinks and includes the contents of the linked-to directories.
The layouts of the resulting tars differ depending on the engrampa/file-roller version and the way it was invoked. Extracting some of these tars fails half-way through with tar errors, the other tars extract without messages.
In all cases the extracts are NOT exact copies of the original directories/files structures - the directory symlinks are changed to normal directories containing the contents of the original linked-to directories. The symlinks to files are still symlinks.

Normally I build my kernels on Slackware Current. To compress /lib/modules/$KERNEL-VERSION I invoke ark 2.6.4 (using Trinity 3.5.13.1). The resultant tar.xz is 21.0 MB.
As an experiment I also built a kernel on Salix 14.0. After invoking engrampa 1.4.0 I noticed that the resultant tar.xz was 50+ MB and still growing. The display showed that it was including files from /usr/src/linux-$VERSION.
Obviously the /lib/modules/$KERNEL-VERSION/{build,source} directory symlinks were followed and their contents included.

A more managable recreation is as follows:

1. In a working directory create a directory "A" with a file "A.txt" in it.
   Likewise create a directory "B" with a file "B.txt" in it.
   Then in "A" create a symlink to "../B".
2. From the working directory issue "tar cvzf A.tar.gz A ; tar tvf A.tar.gz" : things are as expected.
3. In Thunar rightclick on the "A" directory choose "Create Archive..." to create an "AA.tar.gz" archive. Then issue "tar tvf AA.tar.gz" and see that the "B.txt" file is included as well.
4. Create an empty directory "Z" and try to extract the "AA.tar.gz" archive in it : the untar fails with "tar: A/A.lnk/B.txt: Cannot open: Not a directory".

Actually things are even more complicated. Instead of going via Thunar (step 3 above) I invoked engrampa via the Start > Accessories > Archive Manager, created a new archive (AAA.tar.gz) and added the "A" directory to it. The layout of the resultant archive is different from that of the "AA" one.
Extracting the archive gave no errors. In the extract the "A.lnk" is a normal directory with "B.txt" as a file.

See http://forums.mate-desktop.org/viewtopic.php?f=2&t=1430 for more details.

I tested different compression methods and saw the same symptoms.
I tested different versions of engrampa/file-roller *) and saw comparable
symptoms.
In other words: the problem is generic to engrampa/file-roller.

*) Tested were:
-- engrampa 1.4.0 on Mint Mate 14
-- file-roller 3.4.1 on Xubuntu 12.04
-- file-roller 3.6.1.1 on PartedMagic 2012_12_16.

Please advise.
Kind regards, Dick

Engrampa crashed when I was browsing a .zip file. I couldn't reproduce it afterwards...
Luckily I have got the coredump but haven't got any symbols, but it's official arch package so you should have them and analyze the crash. (mate repository).

Version: mate-file-archiver 1.6.2-1
The Coredump: http://ulozto.net/xuHMYoYt/core-engrampa-1401371829-8465-bz2

I know that version 1.6.2 is considered obsolete, and I should've kept myself up-to-date. From version 1.6.2 to current 1.8.0 haven't changed much so I think this bug may be right. Could you please take a look at it ? I'm sorry if this is already fixed but if it isn't it would be nice to see a more stable engrampa.

I'm using Engrampa on a fresh Arch install, and it happened to me repeatedly that I would open an archive that would wrongly show up as empty. I've attached a screenshot. If I unzip the same archive from the command line it clearly contains some files, but they don't show up in Engrampa:

[hritcu@detained Downloads]$ ls -al sopandcv.zip
-rw-r--r-- 1 hritcu hritcu 230687 Apr 30 21:47 sopandcv.zip
[hritcu@detained Downloads]$ unzip sopandcv.zip
Archive:  sopandcv.zip
  inflating: sop_ZoeParaskevopoulou.pdf  
  inflating: CV_ZoeParaskevopoulou.pdf  

If I extract one file inside a folder (drag'n'drop) to any dir on caja works.

If I extract same file again to same dir, it overwrites the other file without confirmation.

After adding a directory into an any archive engrampa crashes with
$ engrampa
(engrampa:16143): GLib-GIO-ERROR **: Settings schema 'org.mate.engrampa.dialogs.add' does not contain a key named 'update'

I have a normal zip-archive with files and folders in it, trying to drag'n'drop just ONE file to caja leads to the following message in a box:

7-Zip 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=de_DE.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Error:
Cannot use absolute pathnames for this command

First, why 7zip if unzip seems to be the better match anyway? And second... somehow engrampa has an issue with the command syntax of 7zip I think which leads to this error message under some circumstances. Decompression works if the error was not shown before and if for example the whole archive is decpmpressed without drag'n'drop..

I don't know why there isn't a global option to set this across all mate-desktop programs. Pluma uses IEC, Atril uses IEC. Now caja has the option to use IEC but it's not a global one amongst the whole suite. I don't see why it'd be such a hard thing to do.

You talked about wanting to be consistent so why is it that this desktop is so schizophrenic, If you want to use SI so be it but there should be options to switch it's size system.

There has been already released patch for file-roller, which replaces p7zip with unzip. Look here https://bugs.launchpad.net/ubuntu/+source/p7zip/+bug/1382106

Testfile from gnome bugzilla https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/580961/+attachment/1803463/+files/%D7%90%D7%A7%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%20%D7%9C%D7%9E%D7%94%D7%A0%D7%93%D7%A1%D7%99%D7%9D.zip

Gnome-bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=306403

shared-mime-info uses application/x-archive instead of x-ar for *.ar files; data/engrampa.desktop.in.in should do the same.

Hi! First, sorry for my English.

Second, the platform. I use: Debian testing, MATE-desktop installed from repositories. Updated some minutes ago.

Now, the problem. Than I am packing a folder with Engrampa GUI (to bz2), I see a window with progress bar. This progress bar is calcing from current file: 1 file - 1 step. But it is wrong. It must be calced from total size: than I have a folder with variable size files, it is not very interesting, than it runs to 90% in seconds and wait 1 hour to finish.

If my message is interesting for you, but you didn't understand, that I want to say (sorry, for my English again), please, contact me (see my profile "retraktor").

Affects: Linux Mint 17.2 Rafaela RC i386, MATE 1.10, engrampa 1.10.0-1+rafaela

Steps to reproduce:

1. On the MATE desktop, using caja, go to a smb-networked disk drive, containing archive files.
2. Navigate to a folder containing one or more archive files, then double-click on an archive (or right-click and choose "Open with Archive Manager" or "Open with engrampa"). The archive file's format makes no difference in this case.

Results: The engrampa window will always open briefly, then disappear. In kern.log and syslog, entries appear, such as this:

engrampa[4658]: segfault at 4c ip 0807e79e sp bfabdcc0 error 4 in engrampa[8048000+65000]

The number following the "sp" is different each time, but the number following "ip" is the same each time.

Expected result: The engrampa window should open, load the archive, then show the archive's contents, just as with archives on local drives.

Workaround: Copy the networked archive to a local drive, and open it there.

"Could not open this file type
There is no command installed for RAR archive files.
Do you want to search for a command to open this file?"

engrampa 1.8.0
unar 1.8.1
Fedora 20

Example rar file:
http://www.philipp-winterberg.com/download/example.rar