tor browser updater handles full disk poorly
When I run out of disk space while applying the Tor Browser update, it tells me it failed but doesn't say why.
In perfect world it would check there exists enough free space before starting the download.
In my case, I think the download was successfully but it ran out of space while applying the patches. On subsequent launches it did not attempt to redownload it, but continued to fail to apply it. Foolheartedly I removed the "0" directory from the updates directory (so that it would redownload it) just realization that my disk was filled, so I don't actually know if it would've applied the update eventually had I only freed up some space.
Activity
The update process will make a backup copy of the entire Tor Browser $HOME directory, i.e. "/Browser". This includes things like the "Downloads" dir, which can be quite large. After a successful update the backup ("/Browser.bak") is removed.
Making a copy of everything seems unnecessary, makes the update process much lengthier, and renders this problem more likely.
If you set app.update.staging.enabled to false (via about:config), the update will not be staged (which will prevent creation of a duplicate copy of everything) and the update will be applied when you restart the browser. Free space will still be needed for the update file (.mar file) plus some room for applying the update, but it should be much less.
I am not sure what the behavior is when the updater runs out of disk space, but the Tor Browser updater is closely derived from the Firefox one so we should look and see if there are any open Firefox bugs on this topic.
Replying to cypherpunks:
The update process will make a backup copy of the entire Tor Browser $HOME directory, i.e. "/Browser". This includes things like the "Downloads" dir, which can be quite large. After a successful update the backup ("/Browser.bak") is removed.
Making a copy of everything seems unnecessary, makes the update process much lengthier, and renders this problem more likely.
That would explain #18179 (moved), where I continued to make changes to the bookmarks after the updater had downloaded, only to see them reverted once it was applied.
Replying to brade:
If you set app.update.staging.enabled to false (via about:config), the update will not be staged (which will prevent creation of a duplicate copy of everything) That's nice to know, thanks.
But just to state it clearly: I of course consider making a backup vitally important; just maybe not of everything under $HOME. Note that this is salient point: Tor Browser is copying so much stuff because it's backing up its whole $HOME, even though it only actually updates a portion of it.
#22298 (moved) is a duplicate. Also see: https://bugzilla.mozilla.org/show_bug.cgi?id=315278#c36 An error string was added but no code has been written to use it yet.
Trac:
Cc: gk to gk, mikeperry
Reviewer: N/A to N/A
Hello,
I can confirm this. Just yesterday, the updated process crashed my computer. The Linux UI was almost completely unresponsive, I managed to kill -9 the Tor process and related processes after several minutes.
Only today, when the whole ordeal started again just seconds after starting the TBB, I checked iotop and noticed that the Tor updater was the culprit.
Please disable this "staging" stuff, it definitely does more harm than good. Instead of relying on a well-running PC for a few seconds for the update process, the PC has to run many minutes or even hours for the "staging".
Please remember that there are still many people with non-SSD HDDs, where reading and writing at the same time on the same disk is really slow.
This is seriously the only thing that nags me with the TBB, everything else is great.
Trac:
Username: torusers-
Replying to torusers:
Hello,
I can confirm this. Just yesterday, the updated process crashed my computer. The Linux UI was almost completely unresponsive, I managed to kill -9 the Tor process and related processes after several minutes.
Only today, when the whole ordeal started again just seconds after starting the TBB, I checked iotop and noticed that the Tor updater was the culprit.
Please disable this "staging" stuff, it definitely does more harm than good. Instead of relying on a well-running PC for a few seconds for the update process, the PC has to run many minutes or even hours for the "staging".
I am sorry for your pain. I wish we had more data about how many people are affected by this, because I would prefer to leaving staging enabled by default like Mozilla does (but I could be convinced that we should do the opposite if we had more data).
Please remember that there are still many people with non-SSD HDDs, where reading and writing at the same time on the same disk is really slow.
We do test with non-SSD drives :) Out of curiosity, is your disk nearly full or why did you add a comment to this specific ticket? And how large is your Tor Browser directory? It surprises me that making a recursive copy of the browser program files and data would cause so much I/O thrash.
#13433 (moved) is a duplicate.
Trac:
Cc: gk, mikeperry to gk, mikeperry, armamentioned in issue #22298 (moved)
mentioned in issue #28200 (moved)