SUMMARY This behavior does not occur if both source and destination file systems are local. STEPS TO REPRODUCE 1. use Dolphin to copy a big file from a samba share to local file system 2. cancel file copy 3. OBSERVED RESULT incomplete file called file.part remains in destination EXPECTED RESULT incomplete file should be deleted from destination SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.18.80 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.1
Mhh. These two operations are not the same. When a copy crosses protocol boundary it's no longer a copy, it's an upload/download and those do behave differently by design. The cases you want to compare are copying from smb->local (which means the file protocol is in the driver seat) and local->smb (which means the smb protocol is in the driver seat). As far as I can tell they do behave the same. They are different from smb->smb or local->local. These are actual copies and do not even create the .part file, the .part is purely there to resume upload/downloads at a later time without having to start from scratch. This is not a bug. Even so, there are a number of kind of related bugs I've noticed. Notably smb->smb is actually misbehaving.
Git commit 994fcaea5a512a201e7b1d59b27ceede27768104 by David Faure, on behalf of Harald Sitter. Committed on 11/10/2020 at 21:40. Pushed by dfaure into branch 'master'. put minimumkeepsize actually in the netpref KCM I didn't even know it was a thing! by the looks of it the setting only applies to retention of .part files on aborting transfers (that is, files must be at least this size so they get retained on aborting transfers). so the setting is in a form inside a widget and that widget's enabled state is contient on partial marking being enabled M +16 -0 src/kcms/kio/netpref.cpp M +1 -0 src/kcms/kio/netpref.h https://invent.kde.org/frameworks/kio/commit/994fcaea5a512a201e7b1d59b27ceede27768104
A smarter person might have written out what the incorrect behavior was lol. smb->smb doesn't implement resume at all, which on the surface seems fine because partial marking only applies to "uploads" from a user POV. Except an smb->smb copy may be across different hosts at which point it'd probably count as "upload" again. For simplicity it probably makes sense to consider smb->smb copies always subject for partial marking and share much or even all the resuming logic with the local->smb scenario.
This should be fixed in at least 22.04. smb->smb transfers are now subject to the same resume and .part logic as other transfers. That is to say the .part file still remains if you abort a transfer as is expected per comment #1 but will now be correctly resumed when trying to attempt the transfer again.