user interface misleading
A free file archiver for extremely high compression
Brought to you by:
ipavlov
Menu
▾
▴
#2701 user interface misleading
I just created a large archive with 9,000 files and it took 1hr to finish. That was fine. But it took an additional 10 minutes after the user interface said it was 100% done. I waited it out and it finally renamed (did a move) the file in the temp folder to the target file. The temp folder and the target zip file were both on the same drive, a high speed USB thumb drive. My research said all this was normal for the cleanup and pointed out that all 100% done means is that "all input data has been processed". There is no indication that finalization is taking place and that it could be a while. Normally people don't wait long for smaller zip files before the user interface closes quickly. But during those 10 minutes I waited I started thinking worst case scenarios such as a bug, disk space issues, etc., but fortunately my research pointed out this was very likekly a shortcoming in the user interface whch should say (somewhere)
100% — Finalizing archive…
Writing ZIP directory and flushing data to disk. Please wait...
And this would prevent exactly the thought I had: “It’s stuck, maybe I should kill it.”
The current GUI is misleading because 100% + Remaining time 00:00:00 strongly implies the job is finished when it actually may still be doing critical finalization.
I believe this is a legitimate 7-Zip usability bug, or at least a missing status message. Thank you for your attention.
Maybe your usb was slow for data writing by some reason.
What is your usb drive and speed of that usb?
Try to copy some big file to that usb. Maybe you will have similar problems
write more information about issue:
what archive type: zip or 7z?
compression settings
do you create new archive ot update previous version of archive?
number of original files
total size of original files
archive size
cpu
ram size
windows system
Hi Igor,
Thank you for getting back to me so quickly. Your intuition about the USB
bottleneck is spot on, and I was indeed operating under a severe hardware
constraint.
During the 7-Zip operation, I was simultaneously running a 97 GB
ROBOCOPYfrom my internal SSD to the exact same USB 3.0 destination drive. I had to
do this out of necessity due to limited free space on the host (SSD) C:
drive (99.9% full), which also forced me to place the temp folder on the
same USB 3.0 drive.
Here are the system and archive details you requested:
[x] USB Drive and Speed: Source = USB 2.0 thumb drive (in a USB 2.0 port).
Destination/Temp = USB 3.0 thumb drive.
[x] Archive type: .zip
[x] Compression settings: All defaults (Store / virtually zero compression
as most files were JPG/PNG) .
[x] Archive status: Created a new archive.
[x] Number of original files: Approximately 8,578 files.
[x] Total size of original files: 18.7 GB.
[x] Archive size:** ~18.7 GB.
[x] System Model:** Dell Inspiron 13-7368, Intel Core i5 (6th Gen) @ ~2.4
GHz, 8GB RAM and 3.1 GB available during run)
[x] Windows system:** Windows 10 Home (Build 19045).
While the concurrent 97 GB SSD-to-USB transfer completely explains the
60-minute data archiving phase due to I/O thrashing, the 10-minute delay at
the very end was confusing given these real-world constraints. Only later
calculations (after submitting the ticket) confirmed that I caused this
delay.
Providing remote I/T DFIR support for this client necessitated using two
thumb drives and whatever USB ports were available (without trying the USB
Type-C port), etc., etc. This included managing constraints like changing
7-Zip's TEMP folder to a USB drive because the C: drive was 99.9% full. In
my calculations, the updating of the final zip "dictionary" could range
from 38 seconds to the 10 minutes I saw (or worse if both were USB 2.0
ports), depending on where my ZIP TEMP folder was, if I postponed the
ROBOCOPY, and if I hypothetically had two USB 3.0 drives. The situation is
definitely rare but the confusion was a lesson learned (I almost killed
7zip to start over and am glad I did not).
Thank you again for looking into this, and for developing such an
incredible tool. I welcome any thoughts you have. I figured 7zip was
flawless and was merely pointing out that a message would have been helpful
for these rare cases, not questioning 7-Zip's robustness. I am fine if
nothing is done; very few people are aggressive enough to devise
workarounds to overcome constraints.
Best regards,
Harry
On Fri, Aug 28, 2026 at 2:29 AM Igor Pavlov ipavlov@users.sourceforge.net
wrote:
--
Harry Stein
Former Top Thumbtack Pro in the USA
Systems/Network/Performance/Security/Forensics and Support Engineer
📱 972-802-2192 <(972)%20802-2192>
📧 misterharrystein@gmail.com | hstein@harrysteinsolutions.com
🌐 LinkedIn https://www.linkedin.com/in/harrystein | Website
https://www.harrysteinsolutions.com | Facebook
https://www.facebook.com/steinsolutions | Thumbtack Reviews
https://www.thumbtack.com/tx/mckinney/software-developers/dba-stein-solutions#reviews
Related
Bugs: #2701