After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 153281 - Progress bar should be exact
Progress bar should be exact
Product: file-roller
Classification: Applications
Component: general
Other Linux
: Normal enhancement
: ---
Assigned To: file-roller-maint
: 308831 334286 436349 528521 545495 (view as bug list)
Depends on:
Reported: 2004-09-21 13:16 UTC by gbz
Modified: 2020-11-11 19:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Proposed Patch (651 bytes, text/plain)
2004-09-29 09:27 UTC, Subrahmanyam Madduri
proposed patch (4.34 KB, patch)
2006-04-16 19:40 UTC, Sven Rech
none Details | Review

Description gbz 2004-09-21 13:16:03 UTC
When extracting files from an archive, the progress indicator is of
indeterminable type (jumping back and forth).
Wouldn't it be possible to have an exact progress bar? For sure, file-roller is
aware of the sizes of the files to extract, because they are displayed in the
browser. And I presume it should be aware of how many byte has been extracted too.
Comment 1 Subrahmanyam Madduri 2004-09-29 09:27:54 UTC
Created attachment 32059 [details]
Proposed Patch
Comment 2 Sebastien Bacher 2005-01-13 15:14:46 UTC
do you still get this issue ? The progressbar is correct here while extracting ...
Comment 3 gbz 2005-01-16 17:12:57 UTC
Yes, still with file-roller 2.8.1.
Comment 4 Mårten Woxberg 2005-06-23 20:22:56 UTC
Using 2.11.1 and the Extract here option in nautilus, the bar just bounce back
and forth....

It should inform on which archive it's on aswell (for multi-rar archives)
Comment 5 Teppo Turtiainen 2006-03-18 10:53:06 UTC
*** Bug 334286 has been marked as a duplicate of this bug. ***
Comment 6 Teppo Turtiainen 2006-03-18 10:56:45 UTC
*** Bug 308831 has been marked as a duplicate of this bug. ***
Comment 7 Sven Rech 2006-04-13 10:28:18 UTC
Does this pulsing progress-bar only happen, if there is a very big file to extract?
Comment 8 Sven Rech 2006-04-16 19:40:22 UTC
Created attachment 63655 [details] [review]
proposed patch

This patch adds the functionality to show the extraction status. It does this, by watching the size of the files who are extracted.
It stores some information in the fr-command structure.

As far as I could test it, it works great here.
I hope this is usefull for you.
Comment 9 Paolo Bacchilega 2006-06-21 15:28:13 UTC
progessbar behaviour depends on what file type is extracted, the exact progessbar is only available for tar and zip archives.
Comment 10 Benjamín Valero Espinosa 2006-11-11 16:36:34 UTC
I am using version 2.16.1 in Ubuntu Edgy. I have taken a big file (about 200 MB) and compressed and uncompressed it in several ways: rar, zip, tar, tar.gz and tar.bz2.

On compressing, the progress bar always goes back and forth, but with tars, where it has put at 100% on the start and has stayed there all the time. It is a very strange progress indication.

On uncompressing, in every case the progress bar has gone back and forth, even with tar and zip files.

I think this behaviour is not right, but I suppose that it is that way because of the features of the compressing commands, although in other platforms you can see other programs (WinRAR, WinZip) doing that well.

Anyway, as has been said, making the progress bar exact on extracting shouldn't be very difficult, because we only need the full size and the partial size extracted, and both data are known.
Comment 11 João Matos 2008-02-13 09:24:06 UTC
Can somebody look into this?

This feature would be quite nice to have.
Comment 12 Sven Arvidsson 2008-07-03 21:24:33 UTC
*** Bug 436349 has been marked as a duplicate of this bug. ***
Comment 13 Sven Arvidsson 2008-07-03 21:28:11 UTC
Any word on the patch in comment #8? 

Or would it be a better idea to file separate bug reports depending on the file
format? For example, at least the proprietary unrar app displays percentage, it should be possible for file-roller to use this?
Comment 14 Paolo Bacchilega 2008-07-20 19:04:23 UTC
Actually the progress bar was exact only when the archive was opened and then extracted, if the archive was extracted with the nautilus context menu command the progress bar wasn't exact even for tar and zip archives.  Now this is fixed and I have added exact progress support to rar and 7zip archives as well.  The fix is available in the current development version (trunk).
Comment 15 Sven Arvidsson 2008-07-20 22:23:24 UTC
Very cool, thank you!
Comment 16 Sven Arvidsson 2008-07-26 20:42:06 UTC
Hmm, I can't get it to work. I have tried both p7zip-rar and unrar, I still get the pulsating indicator instead of a proper progress bar. 

The only change I have noticed is that when extracting multi volume rar archives with unrar, I now get a progress bar stuck around 50 percent.

I'm using r2385.
Comment 17 Paolo Bacchilega 2008-07-27 07:57:05 UTC
the progress bar is file based, that is it shows you the file that it's  extracting or adding, so if you have a single file in the archive a 50% progress is displayed.
Comment 18 Tim Potter 2009-01-31 20:21:58 UTC
I propose that multi rar extraction/compression progress bar bug be filed separately.  With multi rar format, at the moment the first rar starts to be extracted, the progress bar sits at 50%  and will not move from that point until the entire package is decompressed.

does this seem reasonable?  With someone's confirmation, I will file a separate bug report.
Comment 19 Alexander Kojevnikov 2009-04-05 00:22:30 UTC
*** Bug 545495 has been marked as a duplicate of this bug. ***
Comment 20 Alexander Kojevnikov 2009-04-05 00:23:25 UTC
*** Bug 528521 has been marked as a duplicate of this bug. ***
Comment 21 André Klapper 2020-11-11 19:12:44 UTC is being replaced by We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use file-roller and if you still see this bug / want this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at

Thank you for creating this report and we are sorry it could not be implemented (volunteer workforce and time is limited).