[ftputil] Re: ftputil Digest, Vol 14, Issue 4

[Justin Ezequiel]

> Partial quote from my original reply:
> > Note that there will probably never be a "seek" method because the
> > file object which I get from the socket's "makefile" method has no
> > "seek" method (you can't reposition on the remote side without
> > "reading forward" anyway). On the other hand, if someone really
> > needs "seek" to just satisfy an interface, a "seek" method can
> > probably be implemented. But it will be very slow (e. g. you have to
> > read virtually the whole file over the network to position at the
> > file's last byte).


I must have really been in a hurry (to meet a deadline) to have missed this.
Maybe I read it but it just did not register.

> 
> The temporary file solution will probably be much faster than using a
> "seek" method (if I would implement it):
> 
> Temporary file solution: You download the original data, compress it
> and upload the compressed file. For the compression, zipfile uses the
> fast seek method of the random-access file system.
> 
> Potential FTPFile.seek solution: Since zipfile wants to compress the
> whole file, it has to download the whole file implicitly (even if not
> at once). zipfile will also have to write all the compressed data to
> the remote FTP server. However, a seek method implemented for FTPFile
> would be much slower (see my quote). You end up transferring much
> more data over the network than with the temporary file solution.
> 
> Stefan

Thank you for the explanation.
Thinking about it yesterday, I thought there would be issues with the
seek() method.

I used the temporary local file solution and used targethost.upload(...).
ftputil really makes FTP access much simpler.

ftputil is a time saver particularly now that our sys admins are
asking us to use FTP instead of our usual SAMBA access.