Bug with resume? .filepart renamed on disconnect (until...)

I am trying to use WinSCP's SFTP resume feature. I have it enabled in the preferences, and WinSCP indeed writes to filename.filepart when it is uploading a file.

However, when WinSCP's connection is interrupted ("connection reset by peer" because my wirless AP sucks), the file is somehow renamed on the server from "filename.filepart" to "filename" even though the file is incomplete. Then, when I reattempt the transfer, WinSCP doesn't try to resume, since the .filepart file is gone.


Okay, here is where it gets weird. This bad "renaming on disconnect" behavior happened four or five times, and then one day I decided to manually rename the incomplete remote file from "filename" to "filename.part" before reattempting the transfer. WinSCP then prompted me if I wanted to resume, and it resumed and correctly transferred the rest of the file.

Now that it has done one successful resume, though, WinSCP no longer has the "rename on disconnect" problem -- when a connection is interrupted, the incomplete remote file correctly stays named "filename.filepart"!! I have closed and restarted WinSCP since then and done more interrupted transfers, and it seems fixed. It's possible there is some small difference in the situations that I'm not noticing (e.g., different disconnection causes), but I don't think so.


This is with background transfers (I haven't tried foreground transfers, so I dunno if that matters or not); explorer-style interface; WinSCP 3.7.4.


SSH protocol version: 2
SSH implementation: OpenSSH_3.9p1
Encryption algorithm: aes
Compression: No
File transfer protocol: SFTP (v3)
Can change permissions: Yes
Can change owner/group: No/No
Can execute arbitrary command: No
Can create symlink/hardlink: Yes/No
Can lookup user groups: No
Can duplicate remote files: No
Native text (ASCII) mode transfers: No
The server does not support any STP extension.

Sorry, I have not idea when this can happen. Unless you are able to reproduce it I will hardly find it. Let me know if it ever happens again.

Hi,

Okay, I revise my bug report. Apparently it is not "fixed," since I just had a connection interrupted and the incomplete file was renamed from "filename.filepart" to "filename" on disconnect.

This time the error message was different, though; the first message box was something like, "error copying files to remote side" and the second one was "connection reset by peer." I don't recall ever seeing the first message, even those previous times when WinSCP renamed on disconnect. My putty windows (even to different hosts) all got "connection reset by peer," too, though, so it seems just like the same old network problem rather than an application software problem that's causing the disconnect.

Sorry I can't be of more help in tracking this down, but I am pretty sure this bug exists, and that I think the cause might be related to different disconnection causes.

Anyway, I don't really need any support help, just wanted to mention the apparent bug.

Thanks, prikryl, for a really kick ass program. I have been using WinSCP for several years and appreciate it a lot. (Hmmm, maybe I should actually donate then...)

Hm. I have just tried to emulate "connection reset by peer", but it appearently works correctly. Moreover, it is AFAIK nonsense anyway. If the server closes connection in the middle of the transfer, WinSCP can hardly rename anything, if it looses connection.

So there must be something different in your case.

What I did: I was uploading file to the server. Meanwhile I've logged in using SSH terminal and killed process "sshd: <myusername>@notty". WinSCP looses connection, but the .filepart file remains in the target directory. Next time I connect, I can resume the transfer.

martin wrote:

Moreover, it is AFAIK nonsense anyway. If the server closes connection in the middle of the transfer, WinSCP can hardly rename anything, if it looses connection.

Yes, I considered this when I first posted. I figured that the server process was somehow doing the renaming. I don't know anything about how SFTP works, but I guessed that maybe there was a control stream in which two commands had been enqueued, "upload" and "rename." Or maybe the network failure is initially asymmetric, so WinSCP bails because it isn't getting messages from the server, but the asymmetry of the failure lets WinSCP get the "rename" command out the door.

Really, I don't know. I'm talking out of my ass. But I am pretty sure the problem exists. I have reproduced it in front of my eyes at least twice with these steps:

• start an upload of "filename" with WinSCP
  
• log into shell on server, verify that file is called "filename.part" and that file size is actively growing
  
• unplug the ethernet cable from the back of my wireless AP
  
• wait a couple minutes for connection to die; plug ethernet cable back in
  
• log into shell on server, verify that file is now called "filename" but it's incomplete
  

If I can do anything to try to help track this down (like posting WinSCP or sshd logs if I can reproduce it again) let me know.

martin wrote:

What I did: I was uploading file to the server. Meanwhile I've logged in using SSH terminal and killed process "sshd: <myusername>@notty".

I agree that if you manually kill the sshd process, it's going to be pretty much impossible for the file to be renamed. (Like you said, who would be there to rename it??) Instead, try interrupting the connection by killing the network link, like by unplugging your ethernet cable or disabling the network adapter in Windows.