![]() ![]() Mget: t1MB.txt: file size decreased during transferġ1075584 bytes transferred in 1 second (7.08 MiB/s) Mget: t10MB.txt: file size decreased during transfer Lftp:/> Dev:~/scratch/ test5$ cd Dev:~/scratch/ test6$ lftp -u username,password sftp:// ftp1.XXXX. ![]() test5/t10MB.txDev:~/scratch/ test5$ lftp -u username,password sftp:// ftp1.XXXX. Larger files truncate data at the end of the Dev:~/scratch/ test5$ ls -l ![]() Small files return 0 bytes, yet report no errors and that files transferred. Example tested for 5 different file sizes. Truncation occurs ONLY at the end of the fileĦ) See following example. I built 10MB, 20MB, 30MB, 40MB, 50MB files based on exactly 1024 character size records and got varying numbers of truncated record of ~74 to 267 records If this was a block-size issue, I would expect to see some correlation/ recognizable pattern of truncated data. If this was a charset issue, we would also see corruption or byte count variances > using filezilla GUI client > WORKS PERFECTLYĥ) If this was a MD5 or SHA256, we would see corruption and varying data values. There should be 10000 recordsĤ) > using sftp Record 9734 is the last record and is a partial record. For example data in t1MB.txt file is exactly correct through record 9733. I would still like to use lftp, but can use sftp if I have to.ģ) There is ZERO corruption of data. Lets forget about encrypted or zipped files and focus on basic plain text transfer.ġ) MD5 or SHA256 information will obviously be different if the file sizes are different in byte count sizeĢ) I can successfully get the correct file size (and can decrypt and unzip real data files using Filezilla GUI interface and sftp interactively)
0 Comments
Leave a Reply. |