0

I've been looking through pure-ftpd-1.0.42 source code:

https://github.com/jedisct1/pure-ftpd

Trying to find when it triggers:

https://github.com/jedisct1/pure-ftpd/blob/master/src/pure-uploadscript.c

i.e. when does it run the uploadscript after a file has been uploaded.

If you look in src/ftp_parser.c the dostor method is how a file starts the upload journey. Then it goes to ul_send then ul_handle_data but I get lost at this point. I never see when it says, okay, this file is now uploaded, time to call uploadscript. Can someone show me the line?

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

1 Answers1

1

In the pureftpd_start() function in src/ftpd.c, pure-ftpd starts up and parses all of its command-line options. It also opens a pipe to the pure-uploadscript, if configured; here. Rather than invoking the upload script on each upload (and incurring the fork() and exec() overhead per-upload), pure-ftpd keeps the upload script process running separately, and sends it the uploaded file path via the pipe.

Knowing this, then, we look for where that pipe is written to, using the upload_pipe_push() function. Interestingly, that function is called here, by the displayrate() function, which is called by both dostor() and doretr() in the src/ftpd.c file.

Hope this helps!

Castaglia
  • 2,972
  • 5
  • 28
  • 49
  • this does help, thank u. Now I'm trying to figure how it knows when it's safe to call upload_pipe_push(). What if the user is uploading a big file. It gets 99% done, and the connection drops. The user connects back an hour later and uploads the last 1% with an appe command. How does pureftpd know to wait for that last 1% (i.e. an hour) before calling upload_pipe_push? – Andrew Arrow Apr 05 '16 at 02:30
  • I'm not sure that `pure-ftpd` **can** know that, since FTP doesn't allow a way for clients to tell servers, in advance, how much data the client will be sending. That said, `pure-ftpd` can know whether the data connection dropped for "normal" or for abnormal reasons, and might call `upload_pipe_push()` for the "normal" cases. – Castaglia Apr 05 '16 at 02:32
  • cool and if I was to try and re-create pureftp's logic, how long should I wait before assuming the file is done after an abnormal drop? Is there a configurable timeout for that? – Andrew Arrow Apr 05 '16 at 02:34
  • No, because the server **cannot** know whether the client will actually try to reconnect/re-send the rest of the data. There's no "good" timeout for that scenario. – Castaglia Apr 05 '16 at 02:45
  • I just tried a test. I uploaded 1% of a 1276541542 byte file or about 15 megs. Then I killed the connection abnormally. Then I waited an hour. Then I issued an APPE command and uploaded the rest of the file. The final size of the file on the server after the uploaded finished was 1292326238. i.e. about 15 megs MORE than it should be. Corrupt file. Does pureftp have any solution for this? – Andrew Arrow Apr 05 '16 at 19:32
  • Usually such "corruption" happens when uploading a binary file using ASCII mode (the default mode for FTP data transfers). – Castaglia Apr 05 '16 at 20:28
  • this was done in binary mode. I issued the commands from ftp command line. I think the odd thing here is I purposely issued an APPE command where most FTP clients might start over with a STOR command. – Andrew Arrow Apr 05 '16 at 21:23
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/108339/discussion-between-andrew-arrow-and-castaglia). – Andrew Arrow Apr 05 '16 at 23:14