0

Using pureftpd I uploaded 1% of a 1276541542 byte file or about 15 megs. Then I killed the network connection abnormally to simulate a client getting kicked off their ISP. Then I waited an hour. Then I re-connected and issued an APPE (append) command and uploaded the rest of the file. The final size of the file on the server after the upload finished was 1292326238. i.e. about 15 megs MORE than it should be. Corrupt file. What is correct way for an FTP server to prevent corrupted uploaded files because of late append?

Andrew Arrow
  • 4,248
  • 9
  • 53
  • 80
  • 1
    I think that using APPE correctly depends on the client. Also, a 1276541542 byte file is not about 15 megs. It's over a gig. – daveloyall Apr 05 '16 at 21:28
  • i think u misread that, it's a file that's 1276541542 bytes and 1% of 1276541542 is about 15 megs. – Andrew Arrow Apr 05 '16 at 22:38

2 Answers2

1

What is correct way for an FTP server to prevent corrupted uploaded files because of late append?

There is no way for the FTP server to prevent corrupted uploaded files because the server does not know what the file should be.

But the server can help the client to do a proper upload by implementing the SIZE command. Using this command the client can determine the current file size at the server and thus the position in the file where the upload should be continued. Of course this logic has to be implemented at the client.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • but surely the FTP server can know if the user closed the data connection correctly at the end of all the bytes, or if the user hung up and never closed the connection. The 2nd case means it's a fragement and not a full file. – Andrew Arrow Apr 06 '16 at 15:49
  • @AndrewArrow: not really. If the client process crashes the operating system will close the TCP connection. Or the user explicitly aborts the transfer. The server cannot find out in these cases why the connection was closed, only that it was closed. The ABOR command might help a bit with user initiated abort but not with ftp client crash. – Steffen Ullrich Apr 06 '16 at 15:56
  • @AndrewArrow, ok, let's say that the FTP server could detect an abnormal completion. (For example, 'connection reset by peer'.) What should the FTP server do about it? When is the first time the FTP server learns the correct filesize? – daveloyall Apr 06 '16 at 16:03
  • This is the obligatory "don't use FTP" comment. – daveloyall Apr 06 '16 at 16:04
  • I'm trying to see if if I can get ECONNRESET over here http://stackoverflow.com/questions/36440850/when-a-socket-is-disconnected-in-go-can-i-know-if-it-was-a-good-or-bad-close/36441005#36441005 not sure yet. But if I can, then I can wait and not upload that file to production yet, I'll assume the user has 24 hours to finish the upload. Have to use FTP, I have 1000s of customers that have old computers and limited computer knowledge. – Andrew Arrow Apr 06 '16 at 16:22
  • @AndrewArrow: I doubt that you get ECONNRESET. This error would be set if the peer sends a RST. And a RST is set if the peer closed the connection with data still in the socket buffer. But this is not the case when the ftp client crashes in the middle of an FTP upload because there were no unread data from the server in the socket buffer. – Steffen Ullrich Apr 06 '16 at 16:42
0

i have pure-ftpd answers about it’s upload-script

i’m running pure-uploadscript --run /home/aa/done.rb —daemonize

and my done.rb program is

#!/usr/bin/env ruby
puts "done"
f=File.open("/home/aa/ddd.txt", "w")
f << "test"
f.close

and when I run pure-ftpd —uploadscript and upload a file, sure enough the done.rb program is run.

(I know it’s run cuz there is a new file called ddd.txt)

BUT when I’m uploading a big file and kill the ftp client in middle of upload done.rb is STILL run. (Yes I deleted ddd.txt first.)

Therefore, the answer to the question is, EVEN pureftpd can't handle this because of the limits of FTP protocol.

Andrew Arrow
  • 4,248
  • 9
  • 53
  • 80