Opened 4 years ago

Last modified 9 months ago

#18186 new defect

tor browser updater handles full disk poorly

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-update
Cc: gk, mikeperry, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by teor

Component: - Select a componentTor Browser
Owner: set to tbb-team

comment:2 Changed 4 years ago by cypherpunks

The update process will make a backup copy of the entire Tor Browser $HOME directory, i.e. "<install-dir>/Browser". This includes things like the "Downloads" dir, which can be quite large. After a successful update the backup ("<install-dir>/Browser.bak") is removed.

Making a copy of everything seems unnecessary, makes the update process much lengthier, and renders this problem more likely.

comment:3 Changed 4 years ago by 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) 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.

comment:4 in reply to:  2 Changed 4 years ago by teor

Replying to cypherpunks:

The update process will make a backup copy of the entire Tor Browser $HOME directory, i.e. "<install-dir>/Browser". This includes things like the "Downloads" dir, which can be quite large. After a successful update the backup ("<install-dir>/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, where I continued to make changes to the bookmarks after the updater had downloaded, only to see them reverted once it was applied.

comment:5 in reply to:  3 Changed 4 years ago by cypherpunks

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.

comment:6 Changed 4 years ago by gk

Cc: gk added

comment:7 Changed 2 years ago by mcs

Cc: mikeperry added

#22298 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.

comment:8 Changed 2 years ago by 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".

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.

comment:9 in reply to:  8 Changed 2 years ago by mcs

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.

comment:10 Changed 12 months ago by gk

Cc: arma added

#13433 is a duplicate.

comment:11 Changed 9 months ago by gk

Keywords: tbb-updater added

comment:12 Changed 9 months ago by gk

Keywords: tbb-update added; tbb-updater removed

Renaming keyword to make it a bit broader

Note: See TracTickets for help on using tickets.