Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Re: File deleted remotely even if move to local folder didn't complete

Thanks for your post.

This bug has been added to the tracker:

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

File deleted remotely even if move to local folder didn't complete


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

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".