#12301 closed Bug report (rejected)
Update checks are still run with update checking disabled
Reported by: | Daniel Beardsmore | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | Cc: | ||
Component version: | Operating system type: | Windows | |
Operating system version: | 10.0.19041.508 |
Description
Configuration: disable update checks using Edit → Settings → Updates → FileZilla updates → Check for FileZilla updates automatically = Never
Expected behaviour: no update checking
Actual behaviour: a nag window appears titled “Check for Updates” with the message “Unfortunately information about the new update could not be retrieved. Either you or your system administrator has disabled checking for updates …”
The only two ways that the program can display this message are a) the program has psychic powers that allow it to magically know about updates without checking, or b) it checked for updates when explicitly instructed not to do so.
The program violates the aforementioned setting. If update checking is disabled, then update checking must not occur. Instead, the program checks for the update and then chooses not to tell you anything about it, as if that somehow constitutes not checking. If update checking is disabled, the program must refrain from making any attempt to check. Otherwise, that setting is virtually meaningless. The only thing it does do is prevent downloading the update installers, but if that is what it is intended to do, the setting needs to say “Download updates automatically and display update changelogs” with a notice below it that update checks cannot be disabled, because the user interface and behaviour must match each other. The program cannot be allowed to disobey the user’s instructions. If the setting exists, it must behave exactly as it indicates.
Change History (10)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
Resolution: | → rejected |
---|---|
Status: | new → closed |
You need to update to the most recent version of FileZilla. Outdated versions do not get any support.
comment:3 by , 3 years ago
Every version of FileZilla has the same bug — I am using a much newer version than I was when I reported the bug and nothing has changed. Bugs like this don’t just “disappear”: every new version will have the same bug until it is actually fixed. I do update FileZilla but on my own terms.
comment:4 by , 3 years ago
Resolution: | rejected |
---|---|
Status: | closed → reopened |
comment:5 by , 3 years ago
Resolution: | → rejected |
---|---|
Status: | reopened → closed |
There is no bug, the option works exactly as it is worded, it controls the checking for updates. It does not control the display of known updates, be it from checks done in the past or from the inevitable lapse of time.
comment:6 by , 3 years ago
Resolution: | rejected |
---|---|
Status: | closed → reopened |
Like I said, I cleared out filezilla.xml (except the settings to remove update checks) and the behaviour remains. If this is true, where else is it hiding knowledge of the update? Last time I updated FileZilla on the RDS server (when I got chance to do so — my own account is a non-admin account) I had an up-to-date version, so if it’s now found an update, how did it learn about it? If it knows that an update exists, how does it not know what version it is? How can it be reporting one it already saw, yet have no clue what it saw?
The update system is still broken regardless of what exact process it is following. If it’s not checking, then it cannot know that there is an update. If it is checking, why is it not telling me what it saw?
I’ve not done anything unusual or weird to cause it to get into this state. When update checking is disabled, it still somehow discovers updates at some point and starts nagging you with “Unfortunately …”
There is still some kind of a bug that leads to the “Unfortunately …” message, because it should never get into a state where it is aware of an update without being aware of how it came to know that.
I have now updated it regardless.
comment:7 by , 3 years ago
Resolution: | → rejected |
---|---|
Status: | reopened → closed |
The inevitable lapse of time.
comment:9 by , 3 years ago
Tick-tack tick-tack tick-tack, dummdidummdidumm Kekse! Oh mein Gott, schon so spät. Zeit für ein Update, keine Ahnung welches, aber irgendein Update gibt es mit Sicherheit, wie wieder einmal keinen 6er im Lotto.
comment:10 by , 3 years ago
From your evasiveness, one has to wonder if even you have a clue what the program is doing to arise at the “Unfortunately …” message.
There is a separate behaviour where the program will cache the most recently-discovered update and keep showing (and keep downloading) that update with update checking off. So is this the cause? (It seems unlikely because this “Unfortunately …” message just appeared spontaneously, so it has had to have checked for an update’s existence somehow.)
As a test, I emptied filezilla.xml of everything except the settings to disable update checking, to make sure that there was nothing that was holding knowledge of an update. The behaviour remains the same: the “Unfortunately …” message still appears.
Whatever this is doing, it is not what it is configured to do. I dislike the dishonesty surrounding the update process more than anything.