Forum » Support and Bug Reports »

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.

Options
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)

Options

Topic review

martin

Re: Empty files at receiving end: log reports transferred byte count but shows CPS: 0/s

As the logs says, WinSCP delivered 7635 bytes to the server. The server confirmed the delivery. Anything beyond that is not a WinSCP issue.
Just some hints that might help you with an investigation (and to explain to those who come here looking for "empty files" problems, that this problem is actually not about "empty files"):
Your invalid/corrupted/truncated/whatever file is not empty. It has has 360-something bytes. That's not empty. The ZIP archive might be empty. Though 360 bytes is too much for an empty ZIP archive – empty ZIP archive has 22 bytes. See Empty zip file size shows 22 bytes size. Imo, your file is truncated.
Guest

Re: Empty files at receiving end: log reports transferred byte count but shows CPS: 0/s

Hi Martin,

thanks a lot for your swift reply. The files been transferred by WinSCP are compressed zip archives. /zip is used to create the archives. It works most of the time but every now an than we see the error situation that the archive files are received empty at the receiving server. So, not truncated but empty. Although the process of archive creation and compression did run correct and created the archive including files (i.e. the archive was not empty when passed down to WinSCP for transfer. I've uploaded a zip file containing an example of such an empty archive as it was received by the remote server (file name was "avcdr 091502-310722.zip", size 346 bytes). The zip file contains three screen shots showing that the file is indeed empty "avcdr 091502-310722.zip". Weird thing is that, as said, the creation of the zip archive on the sender's end works just fine and that files get added to the archive as they should. But every now and than the receiving server at the far end receives them for whatever reason empty.

Anyway, following the (I think) relevant snipped of the WinSCP log showing the transfer of that particular file "avcdr 091502-310722.zip", plus two more been transferred in the same session: 
. 2022-07-31 09:15:08.935 File: 'C:\CdrTransfer\Temp\avcdr 091502-310722.zip' [2022-07-31T07:15:02.810Z] [2308]
. 2022-07-31 09:15:08.935 Copying "C:\CdrTransfer\Temp\avcdr 091502-310722.zip" to remote directory started.
. 2022-07-31 09:15:08.935 Binary transfer mode selected.
. 2022-07-31 09:15:08.935 Opening remote file.
> 2022-07-31 09:15:08.935 Type: SSH_FXP_OPEN, Size: 63, Number: 515
< 2022-07-31 09:15:08.935 Type: SSH_FXP_HANDLE, Size: 13, Number: 515
> 2022-07-31 09:15:08.935 Type: SSH_FXP_WRITE, Size: 2333, Number: 1030
> 2022-07-31 09:15:08.935 Type: SSH_FXP_CLOSE, Size: 13, Number: 1284
> 2022-07-31 09:15:08.935 Type: SSH_FXP_SETSTAT, Size: 59, Number: 777
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 1030
< 2022-07-31 09:15:08.935 Status code: 0
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 1284
< 2022-07-31 09:15:08.935 Status code: 0
. 2022-07-31 09:15:08.935 Preserving timestamp [2022-07-31T07:15:02.000Z]
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 777
< 2022-07-31 09:15:08.935 Status code: 0
. 2022-07-31 09:15:08.935 Transfer done: 'C:\CdrTransfer\Temp\avcdr 091502-310722.zip' => '/pkg/prognosis/avcdr 091502-310722.zip' [2308]
. 2022-07-31 09:15:08.935 File: 'C:\CdrTransfer\Temp\avsmcdr 091503-310722.zip' [2022-07-31T07:15:03.873Z] [6858]
. 2022-07-31 09:15:08.935 Copying "C:\CdrTransfer\Temp\avsmcdr 091503-310722.zip" to remote directory started.
. 2022-07-31 09:15:08.935 Binary transfer mode selected.
. 2022-07-31 09:15:08.935 Opening remote file.
> 2022-07-31 09:15:08.935 Type: SSH_FXP_OPEN, Size: 65, Number: 1539
< 2022-07-31 09:15:08.935 Type: SSH_FXP_HANDLE, Size: 13, Number: 1539
> 2022-07-31 09:15:08.935 Type: SSH_FXP_WRITE, Size: 6883, Number: 2054
> 2022-07-31 09:15:08.935 Type: SSH_FXP_CLOSE, Size: 13, Number: 2308
> 2022-07-31 09:15:08.935 Type: SSH_FXP_SETSTAT, Size: 61, Number: 1801
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 2054
< 2022-07-31 09:15:08.935 Status code: 0
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 2308
< 2022-07-31 09:15:08.935 Status code: 0
. 2022-07-31 09:15:08.935 Preserving timestamp [2022-07-31T07:15:03.000Z]
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 1801
< 2022-07-31 09:15:08.935 Status code: 0
. 2022-07-31 09:15:08.935 Transfer done: 'C:\CdrTransfer\Temp\avsmcdr 091503-310722.zip' => '/pkg/prognosis/avsmcdr 091503-310722.zip' [6858]
. 2022-07-31 09:15:08.935 File: 'C:\CdrTransfer\Temp\avsmcdrx 091504-310722.zip' [2022-07-31T07:15:04.919Z] [7635]
. 2022-07-31 09:15:08.935 Copying "C:\CdrTransfer\Temp\avsmcdrx 091504-310722.zip" to remote directory started.
. 2022-07-31 09:15:08.935 Binary transfer mode selected.
. 2022-07-31 09:15:08.935 Opening remote file.
> 2022-07-31 09:15:08.935 Type: SSH_FXP_OPEN, Size: 66, Number: 2563
< 2022-07-31 09:15:08.935 Type: SSH_FXP_HANDLE, Size: 13, Number: 2563
> 2022-07-31 09:15:08.935 Type: SSH_FXP_WRITE, Size: 7660, Number: 3078
> 2022-07-31 09:15:08.935 Type: SSH_FXP_CLOSE, Size: 13, Number: 3332
> 2022-07-31 09:15:08.935 Type: SSH_FXP_SETSTAT, Size: 62, Number: 2825
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 3078
< 2022-07-31 09:15:08.935 Status code: 0
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 3332
< 2022-07-31 09:15:08.935 Status code: 0
. 2022-07-31 09:15:08.935 Preserving timestamp [2022-07-31T07:15:04.000Z]
< 2022-07-31 09:15:08.935 Type: SSH_FXP_STATUS, Size: 24, Number: 2825
< 2022-07-31 09:15:08.935 Status code: 0
. 2022-07-31 09:15:08.935 Transfer done: 'C:\CdrTransfer\Temp\avsmcdrx 091504-310722.zip' => '/pkg/prognosis/avsmcdrx 091504-310722.zip' [7635]
. 2022-07-31 09:15:08.935 Copying finished: Transferred: 16.801, Elapsed: 0:00:00, CPS: 0/s
> 2022-07-31 09:15:08.982 Script: exit
. 2022-07-31 09:15:08.982 Script: Exit code: 0

I've asked the admin of the receiving server to send a copy of the relevant log entries but I did not get it yet.

Regards,
Holger
martin

Re: Empty files at receiving end: log reports transferred byte count but shows CPS: 0/s

This does not look like a network issue.
So are the files empty or truncated (360 bytes)? Or even else? What is the content like?
If WinSCP says it transferred 17.751 bytes, it probably did. The problem is most likely on server-side. Can you post a complete log?
hmx8

Empty files at receiving end: log reports transferred byte count but shows CPS: 0/s

Hello,

I'm using WinSCP in PowerShell scripting to sftp zip archives to a remote server on the same LAN segment (FastEthernet). Occasionally, the files are created on the remote server but are empty (size is around 360 bytes). The WinSCP log shows a value for bytes transferred by at the same time CPS: 0/s. Example: 
Copying finished: Transferred: 17.751, Elapsed: 0:00:00, CPS: 0/s

As for a reason, I can only think of a possible network/connection issue while the transfer took place? However, so far I've not been able to identify any issue or problem with the network. All smooth. Same on the remote server. Any hint where else to look or what might cause the problem?

TIA!

Regards,
Holger

Documentation

Support

Associations

Follow Us