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:
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.
. 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.
