file-roller's progress bar does not indicate amount of progress

Thanks for your bug. The upstream bugzilla already knows about this issue, you
can read about it here: http://bugzilla.gnome.org/show_bug.cgi?id=153281

There probably is a reason for this. The archive manager does not know when it will finish.

Is this issue being addressed at all?

I still experience this behaviour with Ubuntu 7.10 gutsy and the latest file-roller from the apt repository.

I see "proposed patches" in the links provided to bugzilla.gnome.org bugtracker but none of them seem to have been officially applied?

It's quite an annoying "bug".

Right, none of the proposed patches have been applied by upstream maintainers. If the bug it's annoying you a lot, what you can do is help the maintainers downloading the file-roller code, testing the patches and giving feedback at the upstream bug tracker. thanks in advance.

I can confirm this on .7z too.
This is annoying. (how long will it take? 1, 10, 100 minutes? who know?)

see https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/245764

This bug was fixed in the package file-roller - 2.23.4-0ubuntu1

---------------
file-roller (2.23.4-0ubuntu1) intrepid; urgency=low

  * New upstream version:
    New features and user visible changes:
    - Added support for reading and extracting alz archives
    - Added support for rzip compressed files
    - Added support for creating self-extracting zip archives.
    - Added ability to create multi-volume archives.
    - Added support for header encryption. Implemented header encryption for
      7zip and rar archives.
    - Use the 7z command to read/write zip, cbr, cbz archives, and to
      read cabinet, arj, rar and iso archives.
    - Try to get the mime type from magic numbers if all other methods fail.
    - Now the progress dialog is exact when adding, extracting or deleting
      files for tar, zip, rar and 7zip archives (lp: #18250)
    - Do not add the backup files, that is files ending with ~, to the archive.
    - Operations are now more efficient for archives with a long file list.
    Bugfixes:
    - Fixed bug #343201 – Use p7zip for RAR archives? (lp: #44958)
    - Fixed bug #529395 – file-roller will not open 256 AES zip files
    - Fixed bug #515194 – PK 4.5 Zip files
    - Fixed bug #519046 – add x-cbr and x-cbz support (lp: #196171)
    - Fixed bug #336790 – file-roller can't open winzip-10 encrypted files
    - Fixed bug #539629 – Create archive for Trash/Computer
    - Fixed bug #506698 – 7z Filename (header) Encryption request
    - Fixed bug #542541 – icon lookup code is broken
    - Fixed bug #504584 – Incorrect comportment when extracting multi part
      rar files.
   Internal code:
    - Simplified the way to register commands.
    - Allow to compile with Gtk+ 2.12 as well.
  * debian/file-roller.mime:
    - updated to list new mimetypes
  * debian/patches/60_correct_libtool_usage.patch:
    - use AC_PROG_CC since that's required when using the new libtool version
  * debian/patches/70_autoconf.patch:
    - new version update

 -- Sebastien Bacher <email address hidden> Tue, 22 Jul 2008 09:33:36 +0200

> Now the progress dialog is exact when adding, extracting or deleting
files for tar, zip, rar and 7zip archives

I would not consider that "exact" for multi-volume RAR archives.

When I extract a 10 parts RAR, I see:
- the pulsing progress-bar for the 1st file
- a progress bar stuck to 50% for all remaining files but the associated message is indeed correct now

i am using 8.04 and still experience this problem.

i ran into it when making a 7z archive

I am using ubuntu 8.10 and I am still experiencing this problem too with "rar" archives.

Yes, in Ubuntu 8.10 - File Roller 2.24.1, for multi-part RAR archives the progress bar stays at 50% for the duration of the extraction. The status text indicator displays what file part it is currently processing, but that is the only thing that actually works.

I do not know how the RAR file-format works, but I suspect that there is a simply solution for this. Either the lead RAR file's header contains information about the size of the archive, or you can scan the directory for all .rar files of the same name as the given archive - this will give you the maximum number of files. Use this in combination with the knowledge of which file you're on and then you can get a more accurate progress bar. AKA 1/10 -> 10%, 2/10 -> 20%, etc.

i can confirm the progres bar issue for multiple file rar archives. Its stays at 50% for the time of the progres.
No ETA in any file type.

Yes, the bug is open again.

I can also confirm this bug.

On Jaunty this bug is open again.

Yes, this is a perfect candidate for One Hundred Papercuts!

Having moved from Windows to Linux one irritating thing was the lack of a working progress bar in file-roller when I extract rars (and other multipart archives). I know this functionality can work - I used to see the bars work properly in WinZip and WinRAR all the time.

Please fix this for 100-papercuts. It is a small detail that has grown to be a torn in my side.

Thanks.1

the change is not trivial since all the command line tools used don't provide the details required to display that bar

How is that the case when you use the command

unrar e multipart.rar

and the output is a continuous percentage increase as the tool uncompresses
each folder in succession.

It should be trivial to even throw in an analyzer that detects the number of
partial files, divides to give each part a certain percentage, and increases
the amount completed as each part is traversed. Time to complete could then
also be approximated based on the amount of time it takes to complete one
part.

This is using the assumption that the size of these multipart files is equal
(except for the last one usually).

--Tim

On Mon, Jun 22, 2009 at 5:05 AM, Sebastien Bacher <email address hidden> wrote:

> the change is not trivial since all the command line tools used don't
> provide the details required to display that bar
>
> ** Changed in: file-roller (Ubuntu)
> Importance: Medium => Low
>
> --
> file-rollers progress bar does not indicate progress
> https://bugs.launchpad.net/bugs/18250
> You received this bug notification because you are a direct subscriber
> of the bug.
>

rar is only one format there is lot of other formats used too

This bug was originally filed for RAR format archives. There is a fix for this which is trivial it seems, so why can it not be fixed? Since you're basing this fix on the output of command line tools then at least fix what is available (and has been available for some time) as each different format will require it's own work anyways.

Thank you.

 Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.

This is not a trivial change by any means , nor is there an easy fix and therefore not a papercut

 A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

 For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

 Don't worry though, This bug has been marked as "invalid" ONLY in the papercuts project.

I see the same happening when extracting one big RAR file.
The progress bar just keeps moving from one side to the other or after a while it stays half until the end.

I'd say that the ideal would be to have a estimated time or percentage.

It's sad that Ark is completely able to display the progress bar correctly, but Gnome utilities completely fail. KDE wins this battle until this is fixed.

Looking through the current head in bzr, I see this on line 399 of fr-command-rar.c:

                fraction = (double) ++comm->n_file / (comm->n_files + 1);
                fr_command_progress (comm, fraction);

It looks like we're going to have a nice progress bar after all ... someday.

Sadly, it's still present in oneiric with GNOME 3.

Reopening paper cut task as part of a review of closed paper cuts.

Still exists in Trusty.

BUMP

The 100 hundred papercuts is a failure indeed. This bug is opened on 2005. Today in 2016 we don't have file roller that shows properly the progress bar in .tar.7z, rar, etc.

Ubuntu is only focused on mobile leaving desktop users abandoned. It is sad see how I join in 2005 and the great spirit until 2009-2010 and how slow is failing all for silly things.

Please, just put 1-2 developers to fix the papercuts daily 1 month, we should have a lot bugs closed like this.

Still doesn't work. I'm unpacking multi volume archive with 13 files 2gb each. I near to the finish but progress bar is still at the beginning. The number of files to unpack is also frozen at 11919 but using Properties option in Thunar I see that 10602 files are already unpacked.

Still bugged in Bionic x64..
Anyone with solutions?