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

Tananda

Okay, though I think it seems strange that the file size would change (why), I can come into that. In this case however, there could be a check if the file goes from greater than zero to zero and aborts the move in that case.
martin

Tananda wrote:

I think it's the implementation of the server that caused this. However, it's WinSCP that deletes the file and therefore WinWCP is responsible for the deletion in the move process.

I think that WinSCP should therefore check if the file sizes are equal after copying in a move procedure, in case some issue like this happens, regardless of the cause of the actual issue at hand. It seems easy enough to do. Let me know if you think this is reasonable.

It's not unusual that the file size changes, while the file is being downloaded.
Imo, because of one buggy server, WinSCP should not break for other users which are downloading files whose size changes for legitimate reasons.
Tananda

I think it's the implementation of the server that caused this. However, it's WinSCP that deletes the file and therefore WinWCP is responsible for the deletion in the move process.

I think that WinSCP should therefore check if the file sizes are equal after copying in a move procedure, in case some issue like this happens, regardless of the cause of the actual issue at hand. It seems easy enough to do. Let me know if you think this is reasonable.
martin

Re: Data loss after using move, results in 0kB file at target location

Can you reproduce the problem?
Can you post a log file on Debug 1 level?
Tananda

Data loss after using move, results in 0kB file at target location

I logged into primitive ftpd server on Android and used "Move" by dragging a file from the right command window to a local directory on the left, connected using the "Super User" method. To my surprise, the file transferred is an empty 0kB file. However, the original file on the Android device is deleted. The log is as follows: 

. 2019-04-09 21:39:35.343 Copying 1 files/directories to local directory "D:\Users\Tananda\Documents\" - total size: 296,151

. 2019-04-09 21:39:35.343   PrTime: Yes; PrRO: No; Rght: rw-r--r--; PrR: No (No); FnCs: N; RIC: 0100; Resume: S (102400); CalcS: Yes; Mask: *.*

. 2019-04-09 21:39:35.343   TM: B; ClAr: No; RemEOF: No; RemBOM: No; CPS: 0; NewerOnly: No; EncryptNewFiles: Yes; ExcludeHiddenFiles: No; ExcludeEmptyDirectories: No; InclM: ; ResumeL: 0

. 2019-04-09 21:39:35.343   AscM: *.*html; *.htm; *.txt; *.php; *.php3; *.cgi; *.c; *.cpp; *.h; *.pas; *.bas; *.tex; *.pl; *.js; .htaccess; *.xtml; *.css; *.cfg; *.ini; *.sh; *.xml

. 2019-04-09 21:39:35.343 File: '/storage/emulated/0/testfile.png' [2019-04-09T20:37:00.000Z] [296151]

. 2019-04-09 21:39:35.344 Copying "/storage/emulated/0/testfile.png" to local directory started.

. 2019-04-09 21:39:35.344 Binary transfer mode selected.

. 2019-04-09 21:39:35.344 Checking existence of partially transferred file.

. 2019-04-09 21:39:35.344 Opening remote file.

> 2019-04-09 21:39:35.344 Type: SSH_FXP_OPEN, Size: 49, Number: 8963

< 2019-04-09 21:39:35.344 Type: SSH_FXP_STATUS, Size: 17, Number: 8708

. 2019-04-09 21:39:35.344 Discarding reserved response

< 2019-04-09 21:39:37.708 Type: SSH_FXP_HANDLE, Size: 45, Number: 8963

> 2019-04-09 21:39:37.708 Type: SSH_FXP_FSTAT, Size: 45, Number: 9224

< 2019-04-09 21:39:37.714 Type: SSH_FXP_ATTRS, Size: 37, Number: 9224

> 2019-04-09 21:39:37.715 Type: SSH_FXP_READ, Size: 57, Number: 9477

< 2019-04-09 21:39:37.975 Status code: 1

. 2019-04-09 21:39:37.975 10 skipped SSH_FXP_WRITE, SSH_FXP_READ, SSH_FXP_DATA and SSH_FXP_STATUS packets.

> 2019-04-09 21:39:37.975 Type: SSH_FXP_CLOSE, Size: 45, Number: 12036

< 2019-04-09 21:39:38.230 Type: SSH_FXP_STATUS, Size: 17, Number: 9733

< 2019-04-09 21:39:38.501 Type: SSH_FXP_STATUS, Size: 17, Number: 9989

< 2019-04-09 21:39:38.739 Type: SSH_FXP_STATUS, Size: 17, Number: 10245

< 2019-04-09 21:39:39.001 Type: SSH_FXP_STATUS, Size: 17, Number: 10501

< 2019-04-09 21:39:39.256 Type: SSH_FXP_STATUS, Size: 17, Number: 10757

< 2019-04-09 21:39:39.522 Type: SSH_FXP_STATUS, Size: 17, Number: 11013

< 2019-04-09 21:39:39.774 Type: SSH_FXP_STATUS, Size: 17, Number: 11269

< 2019-04-09 21:39:40.030 Type: SSH_FXP_STATUS, Size: 17, Number: 11525

< 2019-04-09 21:39:40.291 Type: SSH_FXP_STATUS, Size: 17, Number: 11781

. 2019-04-09 21:39:40.291 Preserving timestamp [2019-04-09T20:37:00.000Z]

. 2019-04-09 21:39:40.293 Transfer done: '/storage/emulated/0/testfile.png' => 'D:\Users\Tananda\Documents\testfile.png' [0]

. 2019-04-09 21:39:40.293 Deleting file "/storage/emulated/0/testfile.png".

> 2019-04-09 21:39:40.293 Type: SSH_FXP_REMOVE, Size: 41, Number: 12301

< 2019-04-09 21:39:40.301 Type: SSH_FXP_STATUS, Size: 17, Number: 12036

. 2019-04-09 21:39:40.301 Discarding reserved response

< 2019-04-09 21:39:40.365 Type: SSH_FXP_STATUS, Size: 17, Number: 12301

< 2019-04-09 21:39:40.365 Status code: 0

. 2019-04-09 21:39:40.369 Copying finished: Transferred: 0, Elapsed: 0:00:05, CPS: 0/s


Since this seems a large potential for data loss, like happened in my case, I urge the developers to look into this. At the very least, before deleting the original file, there should be a check if the file size at the new location is the same as in the original location.

Documentation

Support

Associations

Follow Us