[QUESTION] - How to properly use resume_transfer about suppaftp

[veeso]

AFAIK you have to seek your file from the REST position first.

[shueit]

In which case ?
I'm already doing it to restart an upload, but regarding restarting a download, even if I seek my local file to the last byte downloaded, the io::copy I'm doing with the data_stream appends the whole file at the end of what I already have, and not just the missing part. For exemple, if my local file contains "AB", and my remote file is "ABCDE", I will end with "ABABCDE" on my local one.

[veeso]

try with Write instead of copy

[shueit]

I didn't find any write method with io lib, and for fs it erases the existing file anyway so I went for this piece of code, replacing the copy lines:

    let mut buf: Vec<u8> = Vec::with_capacity(remaining_bytes);
    data_stream.read_to_end(&mut buf).await.unwrap();
    file.write(&buf).await.unwrap();

But I'm not sure if I understood well what you were meaning with trying with Write instead.

Still, it puts in buf the entire file, and since we store everything in memory the memory consumption becomes really high with big files with that.

[shueit]

After inspecting server side logs between FileZilla client and this crate, I found only 1 difference in the command order when doing REST.
FileZilla does PASV -> REST -> RETR
But your crate does REST -> PASV -> RETR

I made a temporary function in your code source to do a dirty test in order to reproduce FileZilla order, basically resume_transfer and retr_as_stream in a single function, and it worked !

    pub async fn retr_as_stream_re<S: AsRef<str>>(
        &mut self,
        file_name: S,
        offset: usize
    ) -> FtpResult<DataStream<T>> {
        let addr = self.pasv().await?;
        self.perform(Command::Rest(offset)).await?;
        self.read_response(Status::RequestFilePending).await?;


        self.perform(Command::Retr(file_name.as_ref().to_string())).await?;
        let data_stream = TcpStream::connect(addr)
            .await
            .map_err(FtpError::ConnectionError)?;
    
        self.read_response_in(&[Status::AboutToSend, Status::AlreadyOpen])
            .await?;
        Ok(DataStream::Tcp(data_stream))
    }

I didn't test it for the upload, but I'm pretty sure that it's the same problem, since the code and command order are quite the same of what I saw.

If you could fix this it would be much appreciated ^^

Edit : RFC3659 document stipulates that

The REST command must be the last command issued before the data transfer command that is to cause a restarted, rather than a complete, file transfer. The effect of issuing a REST command at any other time is undefined. The server-PI may react to a badly positioned REST command by issuing an error response to the following command, not being a restartable data transfer command, or it may save the restart value and apply it to the next data transfer command, or it may silently ignore the inappropriate restart attempt.

Source : https://datatracker.ietf.org/doc/html/rfc3659#section-5.3