Created attachment 159470 [details] Plugin settings This is most likely a duplicate of Bug 402824 and Bug 382599 and their duplicates, but it differs. I invested way too much time into this little test.. but there are multiple issues with the progress bars in Ark. I don't know if this should be split into multiple bug reports. Plugin settings are in the attachment. ------- Packing ------- All testing was done in Ark, not from the context menu. A single asset file from a game (6.3G) was archived with all formats available to me. Packing failed: - .jar: It's just skipping the file - .tar.lzo: Error "Could not set the compression method." Progress broken (ping pong): - .7z - .rar (RarLabs) - .tar - .tar.bz2 - .tar.gz - .tar.Z - .tar.lrz - .tar.lz4 - .tar.lz - .tar.lzma - .tar.xz Progress broken (jumps to 50% and no progress, jumps to 100% when done): - .tar.zst Progress 0-50%: - .zip Adding a second file to .tar.zst yields the same result. Adding a second file to .zip results in starting at 25% and ending at 50%. Third 33% to 50%. etc. Adding a second file to the other formats results in ping pong. On my system there is no option to create a multi-part .zip file, which would be worth to test. ---------------------------------- Unpacking via Dolphin context menu ---------------------------------- Unpacking is a mess tbh. I measured the time it takes to process the archive until the file list is loaded. At this point a dialog is opened asking if the file should be replaced. In this time there is a ping-pong progress bar shown. After the extraction starts there is progress on the most formats, but it ends at 50% and is finished afterwards. One exception is .tar.lrz, which jumps to 49% after 30 seconds and is loaded after 286 seconds. It progresses to 100% in 282 seconds afterwards. There is no progress at all on .7z files, just ping pong. Files in .zip or .rar format jump to 50% and have no progress until they jump to 100%. Unpacked via Ark, they just ping pong. I tested both: unrar and rar (RarLabs) -------------------------------- Unpacking in Ark (drag and drop) -------------------------------- Unpacking via Ark per drag and drop does not have any progress for any file (ping pong in Dolphin / scrolling in Ark). .rar and .7z files request to replace the existing file after extraction, unlike all other formats. --------------------------------- Unpacking in Ark (extract button) --------------------------------- This seems to work for the most types, unlike single file actions. The .rar, .zip and .7z files show only the waiting indicators (ping pong). The .rar and .7z files request to replace the existing file immediately. ---------- Conclusion ---------- There are multiple issues regarding the progress. 1. There is only a waiting indicator (ping pong) if the extraction was started from Ark via drag and drop (single file). 1.1. There is a progress bar if the extraction is done via the "Extract" button, as it is a different action (whole archive). 2. Creating an archive in Ark also only shows a waiting indicator for most types. 2.1. Same for Dolphin context menu's .tar.gz. 2.2. The .zip progresses from 0% to 50% in Dolphin. It ends at the compressed size ratio. (if the archive is 66% the size of the input, it ends at 33%) 3. Unpacking via. context menu is a multi step effort. The archive's file meta data is read first. 3.1. Unpacking via. Ark is different, as the meta data is already read. 4. Checks if a file has to be replaced, should be handled by the parsed meta data, not after unpacking by file transactions. (Drag and drop .rar / .7z) 5. The progress of adding a file to a .zip should start at 0% ---- Progress bars are always difficult to implement.. you never really know how long something takes. There are basically two naive approaches. First, use the file count. Second, use the file size. Both can be problematic in a mixed set of small and big files. File size might be a better option, but could be misleading if lots of small files slow down the process. Possible solutions: - At least for a single file operation the file size would be helpful - One good solution might be to show two progress bars: current file (file size) and overall progress (file count or file size) - A data transfer rate would make a good addition A major problem might be the info given by used libs.. so one might have to patch the libs or to measure externally the IO created by the program and use this info somehow. ----------------------------- Some additional measurements (extraction from the Dolphin context menu), just for fun: > | Extension | Time until dialog | Time to extract | Total | > |-----------|-------------------|-----------------|-------| > | .7z | 0 | 59 | 59 | > | .rar | 0 | 33 | 33 | > | .tar | 0 | 21 | 21 | > | .tar.bz2 | 128 | 150 | 278 | > | .tar.gz | 15 | 28 | 43 | > | .tar.Z | 47 | 59 | 106 | > | .tar.lrz | 286 | 282 | 568 | > | .tar.lz4 | 6 | 21 | 27 | > | .tar.lz | 117 | 132 | 249 | > | .tar.lzma | 114 | 127 | 241 | > | .tar.xz | 52 | 64 | 116 | > | .tar.zst | 3 | 19 | 22 | > | .zip | 0 | 32 | 32 | ---- SOFTWARE/OS VERSIONS Linux: Manjaro, Kernel 6.3.5-1 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9
I think this bug maybe should be part of the "15-Minute Bug Initiative" because compressing and uncompromising files with ark is a very basic task that most users do daily and having a broken progress bar is quite a problem.
(In reply to SolidTemperature0 from comment #1) > I think this bug maybe should be part of the "15-Minute Bug Initiative" Yes, it most certainly can be encountered in the first 15 minutes or even in a live session. It ticks a lot of criteria defined by nate in his blog, there also are some duplicates.