This is an issue that has bothered me for several years in dopus, but this time it occured on a critical file on a metered connection and thus caused real world costs. Hence this post.
When transferring large files (or small files) over a network/internet it can happen that the connection breaks for several reasons. When this happens the file transfer window usually hangs at 0 kB/s. The only option is to abort the file transfer and start it again. No problem since dopus has built in resume functionality... one would think...
However when pressing abort dopus sometimes removes the already transferred data, making any resume attempts pointless. That is, dopus deletes the unfinished file.
What is the correct method to abort/stop/cancel a file transfer so that one can try again to resume the file transfer at a later time when the connection has been re-established?
FYI: This happened on a ca 10 GB file after 90% had transferred on a metered mobile connection in a foreign country. Dopus simply removed all transferred data after the connection temporarily went down and forced me to click the abort button, not allowing me to resume the transfer.
Are we talking about FTP/SFTP transfers, or network shares?
Only FTP/SFTP transfers will be resumed. And then only if the server at the other end supports resume.
In this case it was FTP and the server supports resume, but I have no problem with the resume functionality when/if I have a partially finished file to resume.
It is about dopus deleting the already transfered data when one presses abort during a file transfer.
Since the data is deleted it is not possible to resume anything no matter the protocol.
How do I abort a file transfer (irregardless of the protocol) without removing the partially finished file? This is the first step to allowing a resume by any protocol or software.
To clarify my question, when the connection breaks the file transfer window stops at a certain percentage, often without an error message and it does not resume by it self when the connection restores. What is the correct method to close the transfer window without deleting the partially finished file so that I can manually try and resume the file by copying it to the same location again?
It's designed to always leave a partially copied file behind when a copy to ftp is aborted. An aborted copy from ftp will only be deleted if the ftp server reported that it didn't support resume.
Thank you for the clarification.
In this case the server does support resume but dopus/server are probably not detecting it properly. This is not the only server this has happened on, hence I assume there are several FTP server packages that do not report correctly to Dopus.
Is it possible to force dopus to always leave the partially copied file, preferably also for other protocols like network shares, SD cards, etc?
Even if Dopus does not support resume from all these sources, a failed copy could in that case be saved by a separate program or by shell/cmd command. As long as the partially transferred file is not deleted that is.
Edit: I found a workaround for now, if the transfer has stopped, I open the partially finished file in a program that locks the file as in use by the OS, then I abort the dopus transfer window. The files stays intact since dopus di not have permission to remove a file in use. I can then resume the file without issues.