The URL contains a zipped disk image that is larger than 4G. When opening it with ark, ark shows a file length of 0B and when extracting it, the resulting file is corrupt but no error message is given. Extracting it with unzip gives me the correct (and much larger) resulting file. Reproducible: Always Steps to Reproduce: 1. download file from URL provided 2. open it with ark 3. extract the .img file 4. compare with file resulting from unzip <filename> Actual Results: ark claims file size is 0B and unzipped file is corrupt and too short Expected Results: ark shows correct file size and unzipped file is not corrupt and correct length It is well known that several (un)zip programs have problems with files > 4G - ark seems to be one of them. There is a workaround, but it does not involve ark at all but "unzip" instead.
Confirming (when using clizip plugin). Thanks for reporting.
Uhm, the 0B claimed size is definitely a bug. However Ark can extract the .img just fine on my system. How much RAM do you have?
On Monday, December 07, 2015 11:01:09 PM Elvis Angelaccio via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=355969 > > --- Comment #2 from Elvis Angelaccio <elvis.angelaccio@kdemail.net> --- > Uhm, the 0B claimed size is definitely a bug. > However Ark can extract the .img just fine on my system. > > How much RAM do you have? 8 Gigs! And guess what, when I use ark now, I get the correct size and all. But I swear I tried several times before I filed the bug report, and I never got the full 3,934,257,152 bytes. Now I do - every single time. I have no clue what happened in between - I don't think I updated anything. I may have rebooted....... Whatever went wrong initially, it is not reproducible now - except for the cosmetic bug of showing 0B as the file size. So whatever went wrong, it more than likely had to do with my system. Thanks for checking into it!! Ekkehard
> I may have rebooted....... That might explain it :) > Whatever went wrong initially, it is not reproducible now - except for the > cosmetic bug of showing 0B as the file size. So whatever went wrong, it > more > than likely had to do with my system. > > Thanks for checking into it!! > > Ekkehard Glad to hear this. I'm changing the title to better describe the actual bug.
Git commit 4e4f6c7c6362cc68348392ed20b82ae8fe52244b by Elvis Angelaccio. Committed on 08/12/2015 at 10:44. Pushed by elvisangelaccio into branch 'Applications/15.12'. Show correct uncompressed size of huge zipped files The clizip plugin was converting the entries' original size from string to int, but that was not enough for huge files whose size does not fit into an int. We already convert this value to qulonglong in ArchiveModel, so there is no need to do this conversion also at the plugin level. FIXED-IN: 15.12.0 M +1 -1 plugins/clizipplugin/cliplugin.cpp http://commits.kde.org/ark/4e4f6c7c6362cc68348392ed20b82ae8fe52244b