GNOME Bugzilla – Bug 153281
Progress bar should be exact
Last modified: 2020-11-11 19:12:44 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.
Created attachment 32059 [details] Proposed Patch
do you still get this issue ? The progressbar is correct here while extracting ...
Yes, still with file-roller 2.8.1.
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)
*** Bug 334286 has been marked as a duplicate of this bug. ***
*** Bug 308831 has been marked as a duplicate of this bug. ***
Does this pulsing progress-bar only happen, if there is a very big file to extract?
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.
progessbar behaviour depends on what file type is extracted, the exact progessbar is only available for tar and zip archives.
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.
Can somebody look into this? This feature would be quite nice to have.
*** Bug 436349 has been marked as a duplicate of this bug. ***
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?
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).
Very cool, thank you!
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.
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.
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.
*** Bug 545495 has been marked as a duplicate of this bug. ***
*** Bug 528521 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. 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 https://gitlab.gnome.org/GNOME/file-roller/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (volunteer workforce and time is limited).