Created attachment 115339 [details] Information about extracted file and information about packed file SUMMARY Ark archiver can not correctly extract big files. Extracted files are lesser than expected. STEPS TO REPRODUCE 1. Make D:\ Partition on Windows 10 (NTFS) 2. Set mount-point "/dos/" during Graphical installation of KDE neon 3. Unzip any big *.zip file located on "/dos/" or sub-directory using context menu of Dolphin or Ark (on ready Linux system). OBSERVED RESULT & EXPECTED RESULT For example, "q4os-2.6-rpi.r2.zip" downloaded from SourceForge includes "q4os-2.6-rpi.r2.img" (1 862 270 976 bytes), but extracted file weights about 80-90 MiB. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.13.5 KDE Frameworks Version: 5.50.0 Qt Version: 5.11.1 Kernel: 4.15.0-34-generic x86-64 ADDITIONAL INFORMATION Copying file from archive via Dolphin works correctly.
Live session has same issue - Ark (version from live ISO) works incorrectly while unpacking files from NTFS partition.
Can you try again after disabling the libzip plugin? (Settings -> Configure Ark -> Plugin Settings)
I have only that Ark plugins: Bzip2 Gzip Info-zip Libarchive Libarchive (read-only formats) LZMA P7Zip RAR Unarchiver (that item cannot be deselected) Which of them are connected with libzip?
Ok. Please disable P7Zip and try again.
After disabling P7Zip plugin and rebooting system result is still the same.
'sudo unzip' has the same error.
Thanks for the info. Could you provide a link to the q4os-2.6-rpi.r2.zip file?
I had thought that it was Ark bug, but I found that it was Dolphin bug - file manager doesn't update information about unpacked file size automatically. Packed file: https://sourceforge.net/projects/q4os/files/stable/q4os-2.6-rpi.r2.zip At first time unpacked file weights about 90 MiB, but its real size becomes correct. Please rename the bug "Incorrect size of file at Dolphin".
directory size is not 100% reliable either, say when some files are owned by root.
(In reply to KDErobo3me from comment #9) > directory size is not 100% reliable either, say when some files are owned by > root. KDErobo3me , if files are owned by root and not set to be able to be read by others (+o+r) then they will likely be able to be read, this makes sense. Andrey, can you please provide an alternate file that this issue happens with as the 2.6 version that was on sourceforge is no longer there.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!