downloaded Firefox .bz2 binaries no longer extract correctly
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
People
(Reporter: mrmazda, Unassigned)
Details
(Keywords: regression)
Original summary:
downloaded Firefox .bz2 binaries no longer extract correctly
To reproduce:
1-download a firefox .bz2 file (e.g. http://ftp.mozilla.org/pub/firefox/releases/68.9.0esr/linux-x86_64/en-US/firefox-68.9.0esr.tar.bz2
2-follow installation instructions on https://support.mozilla.org/en-US/kb/install-firefox-linux : (tar xjf firefox-*.tar.bz2)
Actual results:
1-extracted files retain archive content's timestamps (based upon individual file build times)
2-extracted directories acquire timestamps equal to current date and time
Expected results:
1-extracted files and directories retain archive content's timestamps (based upon individual file and directory build times)
Comments:
1-last correctly extracting Firefox ESR version: 68.5.0
2-reproducible on openSUSE 15.1 and Tumbleweed, Fedora 32, Debian Bullseye, Mageia 8
3-bunzip2 -k produces same error, as does 'bzip2 -cd firefox-68.9.0esr.tar.bz2 | tar xvf-'
|
||
Comment 1•6 years ago
|
||
I don't see a difference between what http://ftp.mozilla.org/pub/firefox/releases/68.5.0esr/linux-x86_64/en-US/firefox-68.5.0esr.tar.bz2 and http://ftp.mozilla.org/pub/firefox/releases/68.9.0esr/linux-x86_64/en-US/firefox-68.9.0esr.tar.bz2 extract to (except for the dates, obviously).
I'm not convinced this qualifies as a bug either.
|
||
Comment 2•6 years ago
|
||
To clarify, the behaviour you're expecting is for the directories to keep their timestamps based on the archive's date/time?
|
|
||
Comment 3•6 years ago
|
||
Looking into this more closely, the tarballs we release don't include entries for the directories, and so their timestamps get set to whatever the current time is.
What kind of problems is this causing?
|
Reporter | |
Comment 4•6 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #2)
To clarify, the behaviour you're expecting is for the directories to keep their timestamps based on the archive's date/time?
Not the archive file itself, but of all the individual names within the archive.
I've been using mozilla.org binaries since long before Firefox was born. These directories always retained the timestamps from the archive until some months ago. In latest official SeaMonkey (and in Palemoon), they still do. I double-checked 68.5.0 and was surprised to find it indeed was not different. However, farther back in time, it is. This is from Firefox ESR 52.9.0 on Fedora 32 using GNU tar 1.32 (expected behavior):
ls -l | head -n16
total 94417
-rw-r--r-- 1 root root 693 Jun 21 2018 application.ini
drwxr-xr-x 6 root root 1024 Jun 21 2018 browser
-rw-r--r-- 1 root root 0 Jun 21 2018 chrome.manifest
-rwxr-xr-x 1 root root 111328 Jun 21 2018 crashreporter
-rw-r--r-- 1 root root 4003 Jun 21 2018 crashreporter.ini
drwxr-xr-x 3 root root 1024 Jun 21 2018 defaults
-rw-r--r-- 1 root root 157 Jun 21 2018 dependentlibs.list
drwxr-xr-x 2 root root 1024 Jun 21 2018 dictionaries
-rwxr-xr-x 1 root root 172272 Jun 21 2018 firefox
-rwxr-xr-x 1 root root 172280 Jun 21 2018 firefox-bin
drwxr-xr-x 2 root root 1024 Jun 21 2018 fonts
drwxr-xr-x 3 root root 1024 Jun 21 2018 gmp-clearkey
drwxr-xr-x 2 root root 1024 Jun 21 2018 gtk2
drwxr-xr-x 2 root root 1024 Jun 21 2018 icons
-rw-r--r-- 1 root root 10912528 Jun 21 2018 icudt58l.dat
This is from Firefox ESR 68.9.0 on Fedora 32 (not expected behavior):
ls -l | head -n16
total 147325
-rw-r--r-- 1 root root 693 May 27 18:32 application.ini
drwxr-xr-x 4 root root 1024 Jun 17 23:37 browser
-rw-r--r-- 1 root root 0 May 27 19:12 chrome.manifest
-rwxr-xr-x 1 root root 147792 May 27 19:12 crashreporter
-rw-r--r-- 1 root root 4003 May 27 18:26 crashreporter.ini
drwxr-xr-x 3 root root 1024 Jun 17 23:37 defaults
-rw-r--r-- 1 root root 174 May 27 19:12 dependentlibs.list
-rwxr-xr-x 1 root root 14656 May 27 19:12 firefox
-rwxr-xr-x 1 root root 195944 May 27 19:12 firefox-bin
-rw-r--r-- 1 root root 1449 May 27 19:23 firefox-bin.sig
-rw-r--r-- 1 root root 1449 May 27 19:23 firefox.sig
drwxr-xr-x 2 root root 1024 Jun 17 23:37 fonts
drwxr-xr-x 3 root root 1024 Jun 17 23:37 gmp-clearkey
drwxr-xr-x 2 root root 1024 Jun 17 23:37 gtk2
drwxr-xr-x 2 root root 1024 Jun 17 23:37 icons
This is from SeaMonkey 2.49.5 on Fedora 32 (expected behavior):
tar xfj seamonkey-2.49.5-64.tar.bz2
ls -l | head -n16
total 109039
-rw-r--r-- 1 root root 642 Aug 4 2019 application.ini
-rw-r--r-- 1 root root 230887 May 2 2019 blocklist.xml
drwxr-xr-x 3 root root 1024 Aug 4 2019 chrome
-rw-r--r-- 1 root root 40 Aug 4 2019 chrome.manifest
drwxr-xr-x 2 root root 1024 Aug 4 2019 components
-rwxr-xr-x 1 root root 65160 Aug 4 2019 crashreporter
-rw-r--r-- 1 root root 4003 May 6 2019 crashreporter.ini
-rw-r--r-- 1 root root 787 May 2 2019 crashreporter-override.ini
drwxr-xr-x 5 root root 1024 Aug 4 2019 defaults
-rw-r--r-- 1 root root 198 Aug 4 2019 dependentlibs.list
drwxr-xr-x 2 root root 1024 Aug 4 2019 dictionaries
drwxr-xr-x 3 root root 1024 Aug 4 2019 distribution
drwxr-xr-x 2 root root 1024 Aug 4 2019 extensions
drwxr-xr-x 2 root root 1024 Aug 4 2019 fonts
drwxr-xr-x 2 root root 1024 Aug 4 2019 gtk2
This is from Palemoon 28.9.3 on Fedora 32 (expected behavior):
tar xf palemoon-28.9.3.linux-x86_64.tar.xz
ls -l | head -n16
total 100857
-rw-r--r-- 1 root root 429 May 7 16:14 application.ini
drwxr-xr-x 7 root root 1024 May 7 16:47 browser
-rw-r--r-- 1 root root 0 May 7 16:47 chrome.manifest
drwxr-xr-x 2 root root 1024 May 7 16:47 components
drwxr-xr-x 3 root root 1024 May 7 16:47 defaults
-rw-r--r-- 1 root root 127 May 7 16:46 dependentlibs.list
drwxr-xr-x 2 root root 1024 May 7 16:47 dictionaries
drwxr-xr-x 2 root root 1024 May 7 16:47 fonts
drwxr-xr-x 2 root root 1024 May 7 16:47 icons
-rw-r--r-- 1 root root 11696784 Dec 15 2019 icudt58l.dat
-rw-r--r-- 1 root root 899 May 7 16:47 libfreeblpriv3.chk
-rwxr-xr-x 1 root root 530968 May 7 16:47 libfreeblpriv3.so
-rwxr-xr-x 1 root root 59712 May 7 16:47 liblgpllibs.so
-rwxr-xr-x 1 root root 1834944 May 7 16:47 libmozavcodec.so
-rwxr-xr-x 1 root root 212488 May 7 16:47 libmozavutil.so
|
|
Reporter | |
Comment 5•6 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #3)
Looking into this more closely, the tarballs we release don't include entries for the directories, and so their timestamps get set to whatever the current time is.
I've never heard of the possibility of any such absence. How can any archive not include the timestamps of its content and be called an archive? The whole idea is a bit for bit exact match between original and copy, a clone. Each and every extraction should be a perfect match to any other, whenever created.
What kind of problems is this causing?
Inconsistency with extraction behavior of all other archives and archivers I've ever encountered, and the very definition of archive.
|
|
||
Comment 6•6 years ago
|
||
FWIW, this started in Firefox 56, and out of the build system, the directories are there. They are removed by the signing tasks.
|
|
||
Comment 7•6 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #6)
FWIW, this started in Firefox 56, and out of the build system, the directories are there. They are removed by the signing tasks.
Yes, the signing tasks add only files explicitly to the archive.
What what I can tell, the archives do include timestamps for the individual files contained within, just not the directories. I'm confused by what the reporter is trying to show in comment #4. Is the problem that the directories are missing accurate timestamps, or that the timestamps appear to be from 2018, or something else?
Looking at the tarfile referenced, it clearly has timestamps for its files from this year:
curl -sL http://ftp.mozilla.org/pub/firefox/releases/68.9.0esr/linux-x86_64/en-US/firefox-68.9.0esr.tar.bz2 | tar jvt | head -n16
-rwxr-xr-x 0/0 834560 2020-05-27 19:12 firefox/minidump-analyzer
-rwxr-xr-x 0/0 105392 2020-05-27 19:12 firefox/libmozsandbox.so
-rw-r--r-- 0/0 899 2020-05-27 19:12 firefox/libfreeblpriv3.chk
-rw-r--r-- 0/0 899 2020-05-27 19:12 firefox/libnssdbm3.chk
-rwxr-xr-x 0/0 22616 2020-05-27 19:12 firefox/gtk2/libmozgtk.so
-rwxr-xr-x 0/0 241048 2020-05-27 19:12 firefox/pingsender
-rwxr-xr-x 0/0 14424 2020-05-27 19:12 firefox/libmozgtk.so
-rw-r--r-- 0/0 4003 2020-05-27 18:26 firefox/crashreporter.ini
-rw-r--r-- 0/0 825 2020-05-27 18:26 firefox/Throbber-small.gif
-rwxr-xr-x 0/0 172160 2020-05-27 19:12 firefox/libsmime3.so
-rwxr-xr-x 0/0 280688 2020-05-27 19:12 firefox/libnspr4.so
-rw-r--r-- 0/0 164 2020-05-27 19:12 firefox/platform.ini
-rwxr-xr-x 0/0 195944 2020-05-27 19:12 firefox/firefox-bin
-rwxr-xr-x 0/0 14656 2020-05-27 19:12 firefox/firefox
-rwxr-xr-x 0/0 348448 2020-05-27 19:12 firefox/libsoftokn3.so
-rw-r--r-- 0/0 681 2020-05-27 19:12 firefox/updater.ini
Additionally, comment #4 shows -rw-r--r-- 1 root root 10912528 Jun 21 2018 icudt58l.dat, which does not exist in ESR68.9.0, but does exist in ESR52.9.0. ESR52.9.0 was released in June 2018, so the timestamps from that tarball also look fine.
|
|
Reporter | |
Comment 8•6 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #7)
I'm confused by what the reporter is trying to show in comment #4. Is the problem that the directories are missing accurate timestamps, or that the timestamps appear to be from 2018, or something else?
The directories in recent releases are missing the accurate directory timestamps produced from older releases (hence -> regression), from archives of other products, and from types of archives other than bz2s.
|
||
Comment 9•4 years ago
|
||
Aren't you comparing signed tarballs vs non-signed tarballs? Because the former are modified, I don't think there should be a guarantee that the directories should preserve the original timestamps.
Description
•