@U: Please attach a full session log file showing the problem (using the latest version of WinSCP).

It looks like temporary file transfer was already enabled at the time for all files(See attachment), so why did it still delete the config file?

If you want not to overwrite the original file, if the upload fails in the middle, enable transfers via temporary file:
https://winscp.net/eng/docs/resume#automatic

Using 5.17 and noticed if you fail a transfer to remote file, for whatever reasons, it deletes the original remote file. Say editing a config file and then re-uploading, which is what I was doing, it fails to upload, giving a vague reason and listing possible reasons for the failure and then promptly deletes the config file. So now I can't even redownload and re-edit the original config file because it's been deleted and must start all over again from scratch since the file is not even in any of the temp locations in %tmp% or %temp% so I can't just re-open a saved local copy and go from there.

Thanks for your post.

This bug has been added to the tracker:
https://winscp.net/tracker/1592

I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.

Hello,

There's an issue I've had with WinSCP for a few years now, and I thought it might be time to actually post it. It could be a rather critical one, since I've actually already lost files because of it. It's quite easy to reproduce, at least on the server I keep encountering it on.

I regularly move hundreds or thousands of files from a remote FTP server to a local directory. These files are snapshots generated and uploaded from a surveillance camera, and I regularly want to move these files manually to a local archive folder. The connection to said FTP server, for reasons probably entirely unrelated to this, is not very stable. Usually once in about every 100-300 commands, the connection will close for no apparent reason, and I have to reconnect.

So far that's not a problem with WinSCP, as I have the same unstable connection with every other FTP client I've tried. And, incidentally, I've had it with pretty much every other FTP server I ever connected to, so I'll just put that down as the protocol's fault. I read somewhere that this can be mitigated by using active mode, but my particular server refuses the connection if I do that.

What I do think has to be WinSCP's fault, though, is that about once in every 2 or 3 times that such a disconnect happens, it turns out that the remote file has already been deleted, even though the file move has failed. So I actually lost the file! It's no longer found in the remote directory, but it also hasn't been moved to my local target. In my opinion, whatever happens, WinSCP should never initiate the DELE command before the file to be moved is verified to have been stored locally. If these files were more important to me, it might have been bad :) Of course, to be safe, I can always copy instead of move, and delete only once I verified all files are present locally. But I think the client should actually take care of this.

I usually move files by right-click-dragging them from the remote pane to the local pane and choosing "Move" from the context menu. I will try using F6 next time to see if it happens there, too. I have the drag & drop extension installed, but from what I understand, it shouldn't make a difference as long as I drag & drop within WinSCP, and not to an Explorer window.

Also, I found some existing bug reports for similar issues, but they were for very old versions of WinSCP (1.x).

WinSCP version: v5.11.3 build 7995
Issue occurs since: At least v5.9, possibly longer
Windows version: Windows 7 Professional x64
Transfer protocol: FTP
Interface: GUI, Commander
Error messages: (German)
Connection failure:

Verbindung zum entfernten Rechner abgebrochen
Fehler beim Löschen der Datei
'/dlink/Snap_20171012_175507_9045.jpg'

Upon retrying file move:

Using TLSv1.2, cipher TLSv1/SSLv3: ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA, ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

Kopieren von Dateien vom entfernten Rechner schlug fehl.
Snap_20171012_175507_9045.jpg: No such file or directory

I attached a logfile of an example of when I encountered this problem (log level Debug 2). I'll mark it as private since my remote host, IP and username are littered everywhere throughout. The issue happened with file "Snap_20171012_175507_9045.jpg". When the connection was lost, I chose to reconnect, then I got the message about not being able to copy the file because it no longer exists remotely. I clicked "Retry" once, so I got the same message again, before choosing "Abort".

Thanks!
Daniel