FTP Offset larger than file.
bakes at ymail.com
Tue Jul 28 23:59:26 CEST 2009
On Jul 28, 5:36 pm, Dave Angel <da... at ieee.org> wrote:
> Bakes wrote:
> > On 28 July, 15:18, Bakes <ba... at ymail.com> wrote:
> >> On 28 July, 15:01, Hrvoje Niksic <hnik... at xemacs.org> wrote:
> >>> Bakes <ba... at ymail.com> writes:
> >>>> The error I get is:
> >>>> ftplib.error_temp: 451-Restart offset 24576 is too large for file size
> >>>> 22852.
> >>>> 451 Restart offset reset to 0
> >>>> which tells me that the local file is larger than the external file,
> >>>> by about a kilobyte. Certainly, the local file is indeed that size, so
> >>>> my local script is doing the right things. I do wonder what is going
> >>>> wrong, can anyone enlighten me?
> >>> I'd say you failed to take buffering into account. You write into a
> >>> buffered file, yet you use os.path.getsize() to find out the current
> >>> file size. If the data is not yet flushed, you keep re-reading the same
> >>> stuff from the remote file, and writing it out. Once the buffer is
> >>> flushed, your file will contain more data than was retrieved from the
> >>> remote side, and eventually this will result in the error you see.
> >>> As a quick fix, you can add a file.flush() line after the
> >>> file.write(...) line, and the problem should go away.
> >> Thank you very much, that worked perfectly.
> > Actually, no it didn't. That fix works seamlessly in Linux, but gave
> > the same error in a Windows environment. Is that expected?
> This is a text file you're transferring. And you didn't specify "wb".
> So the Windows size will be larger than the Unix size, since you're
> expanding the newline characters.
> getsize() is looking at the size after newlines are expanded to 0d0a,
> while The remote file, presumably a Unix system likely has just has 0a.
> I think you'd do best just keeping track of the bytes you've written.
Thank you very much, that worked perfectly.
More information about the Python-list