Resume bug still in 2.2.18

[karmikal]

Filezilla resumes while OVERWRITE is selected

In my case the file on the host is appended to the
size of the file on the client. If the size on the
host is smaller or same, the file is left untouched.
(The REST command starts at the host file size)
This often and apparently randomly causes files to be
uploaded incorrectly.

Note the APPE appear all of a sudden in the commands
log below

---

Status: Connected
Status: Starting upload of
d:\post_production\maps\0000000451.gif
Command: PWD
Response: 250 "/Zoom1Images/maps/": is current
directory.
Command: PWD
Response: 257 "/" is current directory.
Command: CWD /Zoom1Images/maps/
Response: 257 "/Zoom1Images/maps/" is current
directory.
Command: TYPE A
Response: 250 "/Zoom1Images/maps/": is current
directory.
Command: PWD
Response: 200 Type set to A.
Command: PASV
Response: 257 "/Zoom1Images/maps/" is current
directory.
Command: TYPE A
Response: 227 Entering Passive Mode
(192,168,111,7,107,192)
Command: LIST
Response: 200 Type set to A.
Command: PASV
Command: TYPE A
Response: 150 Opening ASCII mode data connection
for /bin/ls (31547 bytes).
Response: 227 Entering Passive Mode
(192,168,111,7,74,91)
Command: LIST
Response: 200 Type set to A.
Response: 226 Transfer complete. 31547 bytes in
0.17 sec. (179.114 Kb/s)
Response: 150 Opening ASCII mode data connection
for /bin/ls (31547 bytes).
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode
(192,168,111,7,76,88)
Command: APPE 0000000292.gif
Response: 125 Ready to receive "0000000292.gif"
(restart at 47441 bytes). Mode STREAM Type BINARY.
Response: 226 Transfer complete. 31547 bytes in
0.00 sec. (30807.617 Kb/s)
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode
(192,168,111,7,78,37)
Command: STOR 0000000451.gif
Response: 125 Ready to
receive "0000000451.gif" . Mode STREAM Type BINARY.
Response: 226 Transfer complete. 79 bytes in
0.03 sec. (2.489 Kb/s)
Status: Upload successful

[karmikal]

It appears this behavior happens ONLY when entire folders
are uploaded and there are files within the folders on the
client that are already on the host.
My guess is that somehow the settings for Resume/Overwrite
are not properly recursed/propagated into folders.

[zubinmitia]

It seems that sometimes php (or other text files) are
uploaded in ascii mode.
I solved (or it seems to be solved) in this way:
in ascii/binary settings check BINARY as default transfer
file and DELETE ALL ascii file extensions.

Hope this helps

[daveg1]

This is to confirm that resume may create a destination file
composed of the original fragment plus the complete source
file. Or at least the transfer did not stop at the correct
size. This is not just the case when ftping an entire
folder, but also may occur when transferring a single file.

I had to overwrite. I will upgrade to 2.2.24a as soon as
this transfer is completed.

[daveg1]

2.2.24a still adds the entire file to a fragment during a
binary resume attempt.

Not certain that this is the same bug. Should I open a new
bug rather than adding comments to this one?

[tommywu]

​http://sourceforge.net/tracker/index.php?func=detail&aid=1514840&group_id=21558&atid=372243
I just file a patch, I think it is the same problem, it will
be fixed by this patch.

[Alexander Schuch]

This bug has been fixed quite some time ago already.

tommywu (see below) figured out the problem and a patch has been added to FileZilla 2. According to the changelog, FileZilla 2.2.26 contained the fix at first. The latest version of FileZilla 2 as of this writing is 2.2.32, where the problem should (still) be fixed.