Opened 14 years ago

Last modified 12 years ago

#1004 closed Bug report

Resume bug still in 2.2.18

Reported by: karmikal Owned by: Alexander Schuch
Priority: high Component: FileZilla Client
Keywords: Cc: karmikal, Alexander Schuch, zubinmitia, daveg1, tommywu
Component version: Operating system type:
Operating system version:

Description

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

Change History (6)

comment:1 Changed 14 years ago by 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.

comment:2 Changed 13 years ago by 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

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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?

comment:5 Changed 13 years ago by 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.

comment:6 Changed 12 years ago by 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.

Note: See TracTickets for help on using tickets.