Broken transfers in queue always resume, ignore error 451

[Scott M. Sanders]

Files in the queue whose transfers are broken partway
are always resumed by FZ, even if the server doesn't
support resuming.

Resetting a file's queue status doesn't help; you have
to remove the file from the queue and transfer again.

[Scott M. Sanders]

FileZilla trys repeatedly to resume a file in the queue, ignoring error 451

[Scott M. Sanders]

I've attached a log showing an example of when this occurs.
Sorry that I didn't post one before.

I also modified the summary field to more accurately reflect
the nature of this bug.

Even though the server returns the following error...

Command: APPE Apr 2003 newsletter - First Presbyterian
Church, Bucyrus, OH.pdf
Response: 451 Apr 2003 newsletter - First Presbyterian
Church, Bucyrus, OH.pdf: Append/Restart not permitted, try
again.

... FileZilla continues to try to append to the file.
(CuteFTP and CuteFTP Pro do this, too, which FZ appears to
be modeled after.)

I'm no FTP expert, but I think that this particular FTP
server is possibly configured incorrectly. CuteFTP says that
the server supports resumed transfers, and the server
accepts the REST/Restart command, but it doesn't accept the
APPE/Append command, even when REST is sent before it (CuteFTP).

Still, FileZilla should notice error 451 and overwrite the
file instead. It should also note this for future transfers,
perhaps on a per FileZilla session basis.

[cigamit]

Agreed, or it should at least give us the option to "Never
Resume/Append", which really only a work around, but would
make FZ actually usable by me.

[Tim Kosse]

This bug report has been closed due to inactivity and has possibly
already been solved.

You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).