User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

GNU/Linux platform: Ubuntu 20.04 LTS
installed fresh new tb v.91 in $HOME/thunderbird directory
allowed updates in config
now it is stuck in "working v91.0.3, pending v91.1.0" and looping

Actual results:

cd $HOME/thunderbird/update/
bernie@prod:/thunderbird/updates$ date
Do 09 Sep 2021 12:45:15 CEST
bernie@prod:/thunderbird/updates$ ls -ltr
insgesamt 16
drwxr----- 2 bernie bernie 4096 Sep 8 08:36 downloading
-rw-r----- 1 bernie bernie 371 Sep 9 12:42 backup-update.log
-rw-r----- 1 bernie bernie 371 Sep 9 12:44 last-update.log
drwxr----- 2 bernie bernie 4096 Sep 9 12:44 0
bernie@prod:/thunderbird/updates$ cat last-update.log
PATCH DIRECTORY /home/bernie/thunderbird/updates/0
INSTALLATION DIRECTORY /home/bernie/thunderbird
WORKING DIRECTORY /home/bernie/thunderbird
UPDATE TYPE partial
PREPARE PATCH updater
PREPARE PATCH thunderbird-bin
PREPARE ADD removed-files
PREPARE ADD precomplete
PREPARE PATCH platform.ini
PREPARE PATCH omni.ja
PREPARE PATCH libxul.so
failed: 70
calling QuitProgressUI
bernie@prod:/thunderbird/updates$ cd 0
bernie@prod:/thunderbird/updates/0$ ls
update.mar update.status update.version
bernie@prod:/thunderbird/updates/0$ cat update.[sv]*
pending
91.1.0

I have no clue what "failed: 70" is reporting.

Expected results:

the sw update should have finished after one restart of the process.
but this "failed: 70" is persistent.

the bug reappeared with other version.

bernie@prod:/thunderbird/updates/0$ cat update.[sv]*
pending
91.1.1
bernie@prod:/thunderbird/updates/0$ cd ..
bernie@prod:/thunderbird/updates$ cat last-update.log
PATCH DIRECTORY /home/bernie/thunderbird/updates/0
INSTALLATION DIRECTORY /home/bernie/thunderbird
WORKING DIRECTORY /home/bernie/thunderbird
UPDATE TYPE partial
PREPARE PATCH updater
PREPARE PATCH thunderbird-bin
PREPARE ADD removed-files
PREPARE ADD precomplete
PREPARE PATCH platform.ini
PREPARE PATCH omni.ja
PREPARE PATCH libxul.so
failed: 70
calling QuitProgressUI
bernie@prod:/thunderbird/updates$

I found the condition for this event
the biggest file is
bernie@prod:~/thunderbird$ find . -size +160000 |xargs ls -l
-rwxr----- 1 bernie bernie 146392584 Sep 19 18:59 ./libxul.so
the "failed: 70" is always after this file "libxul.so"
my $HOME filesystem is very full. If the file replace is not working any longer (FILE_SYSTEM_FULL) the "failed:70" happens.
cleaning out my $HOME filesystem to have 1GiB free space , the "failed: 70" does not happen and the update succeeds.

request: string "failed:70" should be translated in a more helpful hint like "file system /home is full"

I think we can close this based on comment 3.

Don't you think we should be exiting the process and telling the user there is insufficient disk space! Sounds like another instance of a generic or no notice to the user. Entries in log files are not user notifications. They are developer notifications.

I completely agree with comment 5
A normal user is not digging down in log files. there should be a clear status "FILE_SYSTEM_FULL" reported to user.
libxul.so is currently 150MiB in size. for file exchange we need more then double free space.
a message like "need 500MiB free File system space for application update" should give a clear action advice.

Seems like bug 315278

the bug in comment 7 is on Microsoft OS, but basically the same. no more space for the download of files.
the algorithm is easy.

1. get free space in file system
2. get size of download file
3. if 1) is greater 2) download file
   else error report "download file aaa does not fit into file system, clean file system xxx and get more free space"

[:mkmelin] from comment #7)

Seems like bug 315278

Perhaps it is, but clearly Mozilla have no intention of fixing the issue with 16 years of complete inactivity on the subject. It is probably not all that important to them, as they are not a big disk space consumer. Thunderbird is a big disk space consumer and jumping ahead in leaps and bounds. My address book now occupies 10X the disk space it did in MORK format.

It is also basic user design to gracefully recover from a failure, if Mozilla is not doing it, it is incumbent to Thunderbird to roll it's own design that does actually meet minimal user experience and feedback metrics, lest we see our user base shrink like Firefox's has.

Restarting a failed update without offering a recovery option to the user is actually the height of hubris. Like all of the update code, it relies on lots of resources and the user being comfortable with forced updates. Neither of which is really true.

If we are to continue to use the Mozilla platform, then it is no longer acceptable to just point at decades old bugs that Mozilla have failed dismally to address and wash our hands. Basically with defects like this the platform is not really of sufficient quality to deliver for Thunderbirds needs. Thunderbird needs to devote resources to delivering a quality product. If that involves picking up the ball that Mozilla have dropped and fixing core bugs, developing our own fork that does the work. The end result needs to be a reliable and scalable product that does not just go "not my circus and not my monkeys" when bugs can be traced to the platform.

Good comments. Fortunately, bugs related to bug 315278 are making progress. Let's keep this bug in TB for searchability, and set dependency (setting version to 78 so it's not seen as a "new" bug)