I’m running the KDE spin of Fedora 38. When I try to open a large zip residing on a network share (smb or sftp) in Ark (from Dolphin), Ark will download the whole file to a temporary directory, which shouldn’t be necessary for just browsing the archive. What can I do to make KDE/Ark download only a minimum amount of data to just browse the archive? Downloading a 2 GB archive just to browse it is a waste of both bandwidth and time.
1 Like
I think this is a very good suggestion.
I ran fuse-zip in foreground/debug over a 351M archive, and did a “find” from the mountpoint to show all files.
The /proc/pidoffusezip/io showed:
17224]# cat io
rchar: 1448582
wchar: 245455
syscr: 1043
syscw: 3989
read_bytes: 0
write_bytes: 0
so it took about 1.5 Mbyte to get the contents.
Of course, the remote filesystem should be able to seek in a file, but smb should have this option.
Instead of sftp, you should use sshfs, I assume, to mount the remote directory and then pick the remote zip file with fuse-zip. This works.
1 Like
Well, the point is not only not to generate unnecessary network traffic, but also for it to be seamless. Mounting every single zip is not an option. I did it the other way, mounted the smb share and Ark started to work without the need to download the file, Krusader finally can browse the archive. So it works, if the share is mounted, but not via KIO.
Unfortunately, I’m not an KDE expert, I can’t pinpoint, where’s the issue is. Someone pointed me to the sources of the Ark zip plugin and the library it uses, and it makes no assumptions about where the file resides, so it must be somewhere else. This is odd, because for example, VLC will play (and search to any point) a several gigabyte long file regardless whether it’s via KIO or mounted without having to download the whole file.
Good solution. Both ark and krusader are fine. ark uses libarchive, krusader the grandfather of the zip programs: unzip. Both do not read the whole file to show the contents.
I think the dolphin method is the problem: it is nice that you can offer each program smb://, fish://, sftp:// and so on, but at the end the receiving program only knows how to handle local files so you only can offer a copy.
Mounting smb offers normal files, so is perfectly fine and standard in Unix like systems.
You cannot use VLC as comparison, it has it’s own SMB driver via libsmb, so it has access and seek access to files without any additional software.