Opened 2 months ago

Closed 2 months ago

#12217 closed Bug report (worksforme)

Target file deleted/modified/damaged after long overwrite dialog inactivity

Reported by: bugsymal1 Owned by:
Priority: normal Component: FileZilla Client
Keywords: target file partially overwritten through incomplete overwrite operation Cc:
Component version: 3.48.1 Operating system type: Windows
Operating system version: 7 64-bit / Intel i7

Description

I needed to update the index.html file to reflect new information. I dragged the new version from local site to remote site.

I got the "Target file already exists" dialog, which is set to overwrite. I did not click OK yet, because I was waiting on confirmation regarding the updated information. Target file size was similar to that of source file, since little information was added.

I left the computer for just under 30 minutes with the overwrite dialog still on screen (this was an accident). The connection was active when I left the computer.

When I returned, the dialog was still there and the connection was no longer active.

However, I noticed that the actual website was blank (tested on a couple of devices and confirmed by third party).
I cancelled the dialog that was still on screen and again I dragged index.html from local to remote.

Server reconnected and the overwrite dialog appeared once again.
This time, the target file that was going to be overwritten (index.html) showed up as having a 0 byte size. This is consistent with the blank website I encountered through the browser. I OK that dialog and now the new and updated index is live, no problem.

Unfortunately, I was not able to reproduce this error myself, nor do I have the logs-because the client was set to not save them by default I believe, and I exited the program before deciding to submit a report.
Still I thought this might warrant some looking into.

I did try searching for this bug but did not find it. It was a hard bug to search for, language-wise.

Attachments (4)

filezilla.log (15.7 KB ) - added by bugsymal1 2 months ago.
FileZilla log, minimally redacted (username, domain, local folder).
log from UI.txt (4.5 KB ) - added by bugsymal1 2 months ago.
Log as seen in UI, minimally redacted (username, domain, local folder).
transfers.png (22.0 KB ) - added by bugsymal1 2 months ago.
Screenshot of transfer list.
overwrite.png (144.5 KB ) - added by bugsymal1 2 months ago.
Screenshot of overwrite dialog showing target file's 0 byte syze.

Download all attachments as: .zip

Change History (6)

comment:1 by bugsymal1, 2 months ago

It just happened again. There were no delays this time, though.

This time I did as follows:

I dragged the remote, older index.html to the local folder (to back up that version).
Then I dragged styles.css from local to remote. I OK to overwrite.
Then I dragged the new index.html from local to remote. I OK to overwrite (target file has normal size).

At this point, I think the overwrite dialog appeared again, as if I were trying to upload index.html for a second time. However, this second time the target file had a 0 byte size.

I confirmed by visiting the website, landing page was blank.
I downloaded the empty index.html to check it. It is indeed absolutely empty.

Finally, I proceeded to re-upload the most recent version of index.html. No issues this time.

Fortunately, I have logs and screenshots this time around. I will upload them in successive comments.

by bugsymal1, 2 months ago

Attachment: filezilla.log added

FileZilla log, minimally redacted (username, domain, local folder).

by bugsymal1, 2 months ago

Attachment: log from UI.txt added

Log as seen in UI, minimally redacted (username, domain, local folder).

by bugsymal1, 2 months ago

Attachment: transfers.png added

Screenshot of transfer list.

by bugsymal1, 2 months ago

Attachment: overwrite.png added

Screenshot of overwrite dialog showing target file's 0 byte syze.

comment:2 by Tim Kosse, 2 months ago

Resolution: worksforme
Status: newclosed

The original transfer failed, for some reason the data connection could not be opened for some reason, most probably some firewall somewhere.

Due to the way FTP works, the command to initiate the transfer and truncate the file to 0 size typically happens before the data connection gets established, so if the data connection fails, the original file is already gone.

Due to line ending conversion on text files, automatic resume of failed transfers is not possible for text files, hence the repeated prompt.

Note: See TracTickets for help on using tickets.