Invalid access to memory after timeout when grabbing a file

Version 6.2 beta (Build 14434 2023-10-05) portable

Reproducible by attempting to do an SFTP file transfer from a router via a socks proxy, file transfer also fails on versions 5.21.7 and 6.1.2, but does work with FileZilla. Cannot directly connect to this router.

Happenings: Successfully logs into router, retrieves directory list, when file is dragged across for copying from the device, it times out.

For the attached log file the following command was issued from a "cmd" prompt -->

Thanks for your report. Though I cannot reproduce the problem.

I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

Thank you Martin,

I have registered now, please note I must use a portable version, and if it was not a link it was likely stopped before I can see it.

Thanks. I've sent you new email.

Thank you Martin,

I've attached a zip of the output, but I did not see the Invalid Access to memory, yet the SFTP still timed out.

Thanks. Do you have an access to that server without proxy from some other location? Or do you have another SFTP server (something more standard – OpenSSH) that you can access via the SOCKS proxy? I'm trying to narrow down the problem. Both SOCKS and Cisco are rare on their own, let only their combination.

WinSCP does not receive a response to FSTAT request from the server. FileZilla does not use FSTAT for a regular transfer. So that might be, why the download works in FileZilla.

One think you can try: The FSTAT would be used by FileZilla, when resuming the transfer. So can you abort download of a file in FileZilla and retry it (selecting "Resume")? (and post FileZilla log file for that)

Thank you again Martin,

Unfortunately, filezilla, whilst aborted, and resumed twice during the transfer showed no issues. I also tried shutting the application down mid transfer, and it was able to resume as well upon restarting and re-connecting.

I've attached the log.

Sorry, I was wrong. FileZilla uses FSTAT when resuming upload, not download. Can you try that?

What about my other questions?

Thanks Martin,

When the upload is broken, FileZilla starts again and does not resume.

As for your other questions, sorry I missed adding the response in.

• No the only access to that server is via a proxy
  
• Access to a Linux (Centos) server, does work through the same proxy.
  

Please post FileZilla log for resume attempt.

Sorry, I have attached the one I just did for you, aborted once during the process.

FileZilla logging is not very detailed, but I believe this indicates the same problem WinSCP is facing with your server:
So I'm pretty sure it's a server-side bug.

Thanks again Martin,

That the server is doing something wrong, doesn't overly surprise me, that being said, FileZilla was still able to send the file, after the above-mentioned disconnection, without user intervention, beyond requesting if to override the partially sent file or not.

If you plan to leave it at this point, I understand, it means for these devices I need to use an alternate application.

As I wrote, FileZilla (actually pysftp, internally used by FileZilla) happens to use another API to query size of the file. So it avoids the bug.

Though even its download code contains this comment:
So it might happen that future versions stop working with your server too.