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


Imo, what happens is that complete file is buffered somewhere on the way between WinSCP and the server (or even on the server itself). So from WinSCP perspective, the transfer is done and the server is not responding for too long. I do not think that there's a way for WinSCP to distinguish this situation as "running transfer" as opposite to server failing to respond.

Hi Martin,
thank you for your reply.

Best would be, you can monitor the running transfer and dont run into any timeout value during this. But I dont know, if this is technical possible.

Maybe reducing the transferbuffer will help?

If this two options are not possible, a second timeout-value "waiting to complete transfer" would be nice.

Kind Regards

Re: transfer of large file over slow connections run unnecessary in a timeout.

Thanks for your report. What do you propose? A separate timeout for the upload, different from the connection timeout?

transfer of large file over slow connections run unnecessary in a timeout.

Steps to reproduce:
- send a large files (~110MB) over a slow connection (home-dsl) via webdav

What happens:
- winscp show "fast" sending and the progressbar will grow until 95-99%.
- transfer in the winscp-gui stalls
- errormessage after 15 seconds (this is the default timeout value)
"Netzwerkfehler: Zeitgrenze für Verbindung „“ wurde erreicht.

Could not read status line: connection timed out"

At the moment of timeout, the transfer to the server is NOT complete, the destination file (.davfs.tmp1ff369) is about 80 MB.
The temp-file is still growing till the end (~110MB) and will be renamed after this correct. The transfer will complete successful, but WinSCP did not recognise this due the previous timeout.

Workaround 1) Changing timeout to 90 seconds.
WinSCP will wait longer, so the transfer has time to complete, but unfortually this Timeout will also used while creating connections.

Workaround 2) Set the Transferspeed very low and not to "maximum"
Will cause same "progress-state" at sender and reciever, but not the maximum available speed will used.

OS: Windows 10
WinSCP Version 5.19
Transfer via WebDAV and SSL

OS: Debian 10
Apache2, Mods: dav, dav_fs, dav_lock

Entferntes System = Apache/2.4.38 (Debian)

Dateiübertragungsprotokoll = WebDAV
Kryptografieprotokoll = TLS/SSL-implizite Verschlüsselung, TLSv1.3
Verschlüsselungsalgorithmus = TLSv1.3: TLS_AES_256_GCM_SHA384, 4096 bit RSA
Komprimierung = Nein
Fingerabdruck des Zertifikats
SHA-256 = be:74:c7:ee:74:6c:61:1a:00:5f:77:41:91:03:82:45:d9:9f:3f:d2:25:a1:7c:8d:11:c6:e3:10:66:77:ad:88
SHA-1 = 3a:a4:ec:3a:75:09:01:3f:55:46:d2:5b:00:24:fa:1b:86:de:73:5e
Darf Berechtigungen ändern = Nein
Darf Besitzer/Gruppe ändern = Nein
Darf beliebige Befehle ausführen = Nein
Darf symbolische/harte Verknüpfung erzeugen = Nein/Nein
Darf Benutzergruppen herausfinden = Nein
Darf entfernte Dateien duplizieren = Ja
Darf verfügbaren Platz ermitteln = Ja
Darf Dateiprüfsumme berechnen = Nein
Native ASCII-Textmodus-Übertragungen = Nein
Zusätzliche Informationen
Der Server unterstützt diese WebDAV-Erweiterungen:
  1, 2, <>
Gesamter Speicher auf Gerät = Unbekannt
Freier Speicher auf Gerät = Unbekannt
Gesamter Speicher für Benutzer = Unbekannt
Freier Speicher für Benutzer = Unbekannt
Bytes pro Zuordnungseinheit = Unbekannt