That’s normal and expected. And inherent limitation to any network file system (not specific to KDE or Linux).
A smb share is a network share, meaning all data reading and writing must go through the network and is slow compared to local folder.
In order to compress files, we need to read them them all and then write a new file of a potentially similar size.
If we were to allow compressing from a smb share, you would be copying locally the file(s) to compress, compress them and uploading the new compressed file to the server, which would be very noticeably slow and potentially not expected behavior.
If that’s what you want, you can do it manually.
Or if you can, you can compress on the server through ssh.
I agree that the network is slow, and that compressing remote files to a remote archive is inefficient. However this isnt the case if you’re trying to compress remote files to a local archive.
I don’t think this is normal and expected. I can do this just fine on Windows for example with 7zip. The compressor reads the files directly from the SMB as it compresses it locally.
A network share is indeed slow. But having to copy the file to local storage and then compressing it is probably slower. Anyway, the bottleneck of compression is probably going to be the compressor and not the network, especially if you’re connected to ethernet. (then again, I have a 7th gen i5 … dunno what the new CPUs are like )
Compressing on the server with ssh is possible, but not all servers have ssh (e.g. Windows computers), and that may still take longer than simply compressing it from the network directly, because you’d still have to transfer the compressed file afterwards.
Shouldn’t this functionality be handled by kio anyway? I guess this was my expectation, that KIO abstracts away things like network shares.
Just for the record. Compressing on network drives works transparently if you mount network shares with fstab, autofs or systemd-mount or fuse instead of KIO and yes it can be slow and result in unneccessary waste of bandwidth. So, ymmv
It is exactly as slow as if KIO+ark would do it, because that’s the only way it can happen.
Depend on the size of the file(s) you are considering, and their number, the compress algorithm, network speed and much more.
We must place ourselves always in the worse case scenario to evaluate things, because those will happen and users will report bugs then.
Also the application has no way to differentiate LAN and internet, and even then a slow LAN can be slower than some internet connections.