#12389 closed Bug report (wontfix)
ETA/Size of downloads when filesize is incorrect
Reported by: | meteorquake | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | Cc: | meteorquake | |
Component version: | 3.52.0.5 | Operating system type: | Windows |
Operating system version: | Win10 x64 |
Description (last modified by )
If you have two instances of FZ open (eg you might have on two computers) and one fetches a directory listing before the other has finished uploading a file, when you download that file (certainly after timeout) FZ doesn't refetch the latest (final) size but assumes what it has is correct, and the ETA is incorrect.
I think certainly once it's passed the projected size it should realise and fetch the correct size and the ETA should be updated, however it may be better in addition if it could check the size before downloading if: the timestamp of the file is close to when the directory was listed and the session had not uploaded it there, as that's a sure sign the size might be incorrect.
Cheers, David
Change History (3)
comment:1 by , 4 years ago
Description: | modified (diff) |
---|
comment:2 by , 4 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 by , 4 years ago
I suppose I'm thinking more of large files that take a good while to download, where the ETA is very useful to know.
How about an adjusted idea then - if the user themself refreshes the directory and the size changes for a file being downloaded, then the downloading file can update its information and provide the correct ETA? I think this would resolve any issues with it automatically fetching the information for you. (That or the above suggestion could apply just to files above a certain size)
David
This behavior won't be changed. File sizes and timestamps are unreliable information.
Checking for a fresh size right before a transfer would delay each transfer by a full round-trip, twice that if also the timestamp would be refreshed. This quickly adds up if you transfer many files over a long distance connection. Refreshing during a transfer would require opening a completely separate secondary connection.
Ultimately though, since the transfer of data and metadata is not an atomic operation, there will always be TOCTTOU even if you were to continuously refresh the metadata.