i'm no expert neither, i just picked up a few things when the QNAP experts do their thing on my nas at home via teamviewer.
i don't even have a linux PC at home, strictly a dos/windows user (hence using winscp as it's got a gui and handles all that minutiae for the user, i like simple things that i can turn on. Like me! lol)
Just my nas that uses some form of linux, idk it's all bundled.
Anyway, i know the following commands work on my nas: stat, top, pidof, kill, cp,mv, du, find, grep (not pgrep)
the "pidof" command where you get your cp process pid, might be useful later.
And i'm no expert either, but i guess there are other integrated basic linux commands you use in winscp.
That is why i use winscp and that is why you have to stay in control of the situation and not just have winscp sit and wait for the server to finish or get a timeout then cut the connection if something goes wrong.
you could either rewrite the whole copy procedure and do a loop and send each file 1 by 1 from source to target with cp/mv
or you could read these 2 links, paying attention to
messages #6 and #2.1 and #2.2
and messages #16 and #11 and #5
this should give you the tools to get the information needed to display in the copy/move box in winscp, to update on the progress of the move or copy.
this all goes in the move/copy box to show the information to the user.
Estimates: #5 and 16 of link 2
it doesn't have all the math but its basic idea is there.
Use 1 main connection to get status information to display in the box on screen and 1 background connection to do the transfer.
This way your program does the same job but is better informed, it stays updated of what happens and you can give the user pertinent information like estimates of time it will take based on the stats you get from the server with another connection.
Display that in the copy/move window and keep that cancel button active
if we press cancel, idk if you can send the cancel signal or just do a brute force thing: kill the process with the pid you already know and if it was in the middle of copying a file then delete the file at destination because the file is only half copied.
With your knowledge of the linux commands it'll only take you a couple hours of testing to figure this all out.
Like i said, put the knowledge about what you do know to your service.
the important thing here is what you do with a timeout.
you could either keep waiting or do what you do now, kill the connection and let the user worry about what's going on.
personally, i'd just try to see if the cp is still going and if it is then don't bother the user with the timeout, just wait it out, giving updates as it goes along.