Double cancellation in FTP for a single file

[browny]

TC 11.51rc1 64-bit, Windows 11
Uploading one file in FTP connection (F5 key).

Press Cancel button; now the action has to be confirmed in the dialog with OK (Stop), Cancel and Finish copying the current file buttons.
But the transfer dialog was still on screen after choosing OK (Stop).
Had to repeat the cancellation sequence again.

This behaviour could make sense if several files were being transferred, and the confirmation dialog requested to cancel the whole queue.
For a single file one confirmation should be sufficient.

[ghisler(Author)]

Not confirmed. When I upload a single file and then click "Cancel" and "OK (Stop)", I get an error message "Transfer aborted". When I then click OK, the copy progress dialog is closed. I also tried with "Download in background", and the background transfer manager gets closed too.

[browny]

I get an error message "Transfer aborted". When I then click OK, the copy progress dialog is closed.

In my case, the progress persists after "Transfer aborted".
If FTP connection is via OpenVPN, later (after timeout?) there would be another messagebox: "Transfer failed, continue operation?"
On answer Yes operation does not continue (of course).

If connecting from the same computer where the FTP server was installed, progress dialog would close, but not immediately - there was sufficient time to click Cancel again, and then OK (Stop) to close.

As if TC is waiting for something before closing the progress dialog.

[ghisler(Author)]

When exactly did you press the Cancel button? I tried it during the transfer of a large file. Maybe you were copying many small files? The you may have pressed it between two files, where multiple commands are being sent and responses are awaited. The log file should show you where it stopped.

[browny]

When transferring a file on the computer with FTP server, log has these lines:

Code: Select all

Upload: 489,848,832 bytes, 142,220 kbytes/s, 1 s
Cancel pressed!
Upload: 505,937,920 bytes, 49,829 kbytes/s, 3 s
Cancel pressed!
Get directory
TYPE A
200 Type set to A
PASV
227 Entering Passive Mode

Seems like upload proceeded a bit after the first cancel.
Is there any hidden data queue? Then if it got empty quickly, tranfer dialog closed without long delay, otherwise it hanged around for a while.

An internal cancellation flag and ignoring further button actions might be considered - as faster and more reliable than Windows messages.
Though buttons could be disabled after the first Cancel too.

[ghisler(Author)]

I'm really sorry but I can't reproduce that. Can anyone else reproduce it? I tried aborting an FTP upload multiple times, both encrypted and unencrypted, and both in TC 64-bit and 32-bit, but it always worked in the same way:
1. Clicked on "Cancel" or pressed ESC
-> Dialog box "User abort!" was shown
2. Clicked on "OK (Stop)"
-> Got message "Upload aborted"

[JOUBE]

I'm really sorry but I can't reproduce that. Can anyone else reproduce it?

I hardly use FTP anymore. But I can confirm it for SFTP too. Since I rarely stop uploads, it rarely bothers me.

I tried aborting an FTP upload multiple times, both encrypted and unencrypted, and both in TC 64-bit and 32-bit, but it always worked in the same way:
1. Clicked on "Cancel" or pressed ESC
-> Dialog box "User abort!" was shown
2. Clicked on "OK (Stop)"
-> Got message "Upload aborted"

Exact. But this does not stop it! Upload goes on.

It is especially true for large files that are obviously still being copied in the background or something. I usually end the whole TC after that and restart it so that I don't have any problems with the connection. It also doesn't delete the "half" file on the server. Maybe that's part of the problem.

[ghisler(Author)]

Exact. But this does not stop it! Upload goes on.

That's what I cannot reproduce. I tried it about 20 times, it ALWAYS stopped.

Keeping the partial file is intentional, it allows you to resume the upload later.

It is especially true for large files that are obviously still being copied in the background or something.

How big? I tried with a 6.6GB file, and upload stopped reliably with both FTP and SFTP.
If the upload didn't stop with the above procedure, how were you able to finally stop it?

[browny]

For low data rate size could be few megabytes - gives enough time to click and transfer did not complete soon after that.

My guess, data was buffered somewhere in the net, and TC waits for response.
In any case, re-entry into cancelling routine is dangerous; could cause crash or endless loop.

JOUBE
1. What is the FTP server in your case?
Mine is FileZilla 0.9.60.2, using plain FTP.
2. What would happen if you simply wait after the first Cancel & OK?
In my case transfers terminate later (as descirbed above).

[JOUBE]

So many questions that I won't quote them individually. Most recently I aborted transferring a win_install_XYZ.iso (approx. 6GB) in the local network from a Windows computer to a Linux computer (Target: Arch/Debian/Fedora? I can't remember) using the usual SSH server. And I don't have the nerve to wait that long after my first break... So I don't know anything else. And it's really not as important as getting back to work quickly. I'll stop the TC anyway for security reasons, delete half the file and that's it (which is ok for me...). My post is just to make it clear that the problem really does exist. And next time I'll just wait a little longer after the first abort. I promise. (It could be something to do with caching). As I said, it's not that important to me.

[ghisler(Author)]

Unfortunately I couldn't reproduce it even after several hours of debugging, so I will move this to "will not be changed".

But I can at least suppress the "bytes copied" message shown after the user clicked on "Abort".

28.01.25 Fixed: FTP upload file: Stop updating "bytes copied" in dialog after "Cancel" was pressed (32/64)

Moderator message from: ghisler(Author) » 2025-01-28, 11:21 UTC

Moved to will not be changed.

[browny]

Now it is like this:

Code: Select all

STOR backupl.zip
150 Opening data channel for file upload to server of "/backup.zip"
Upload: 655,360 bytes, 165 kbytes/s, 9 m
Cancel pressed!
Cancel pressed!
Get directory

At least, Pause and Cancel buttons were expected to be disabled, yet still could be pressed.

[ghisler(Author)]

Yes, I only suppressed these "bytes copied" messages after the user clicked Cancel. I could not find a reason why the aborted state would be lifted after clicking Cancel, sorry. I just don't have enough information.