Ftp - Support partial file download

[tgambet]

Short description

It would be nice to have a way to download a file partially (from an offset) with FTP.fromPath.
This would for instance allow resuming big files downloads.

Details

I suggest adding an offset parameter to the fromPath method that will leverage the fact that the FTP protocol allows resuming downloads from an offset (REST command).

Implementation is straightforward and I started playing with the code to see if it would work
(check tgambet/alpakka@master...tgambet:read-offset).

The tests I added pass fine for the SFTP implementation but not for the FTP/FTPS one. It seems that the Apache FTP server used for tests supports REST commands for ASCII files but not for binary ones, although the command is acknowledged in both cases. I wonder if it wouldn't be best to setup an FTP server with docker instead of using the Apache one to test this feature if it is accepted.

Here is the log from the server for the failing test:

RECEIVED: TYPE I
SENT: 200 Command TYPE okay.
RECEIVED: PASV
SENT: 227 Entering Passive Mode (127,0,0,1,230,128)
RECEIVED: REST 1000010
SENT: 350 Restarting at 1000010. Send STORE or RETRIEVE to initiate transfer.
RECEIVED: RETR /sample_bigger_file
SENT: 150 File status okay; about to open data connection.
SENT: 226 Transfer complete.

Even though the REST command is acknowledged the whole file is sent, a bug which prevents the test from passing. Note that in ASCII mode the REST command does work.

[ennru]

I agree this would be a great addition.
Setting up an FTP server in Docker makes sense to me as well, I suspect some of the tests that fail on Travis from time to time are due to things in the embedded FTP server.

[tgambet]

Great. I don't know much of Docker but I can try to set that up if you want. That would also require quite a lot of work to adapt the test files I think. Should I do it?

[ennru]

Yes, please. I created #1663 for that change.
Updating all the tests and checks there requires quite some work, though.

[ennru]

Implemented with #1671