666495 - SeaMonkey upgrade moved the program files' dates back in time

Status: RESOLVED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[skierpage]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1
Build Identifier: 2.2b1

I had SeaMonkey 2.0.14 installed on Windows Vista.  Most program files were dated in April, e.g. 2011-04-30 03:57PM.  After running the 2.2b1 setup.exe, most program files went back in time to 2010-01-01 1:00AM.

Reproducible: Always

Steps to Reproduce:
1. Look at file dates in seamonkey-2.0.14.zip for Windows
2. Look at file dates in seamonkey-2.2b1.zip for Windows

Actual Results:  
  2011-04-21 00:55 seamonkey/AccessibleMarshal.dll in older SM 2.0.14
  2010-01-01 00:00 seamonkey/AccessibleMarshal.dll in newer SM 2.2b1
It's puzzling at first, and it might confuse programs that track changed files.

Expected Results:  
A newer build has newer files.

Comment 1

[therube]

This is done purposely.

"UA sniffing and fingerprinting issues" & all kinds of related bugs.

Bug 591537 - Freeze UA build id for Firefox branded builds
Bug 583181 - Don't reveal navigator.buildID to every site on the web 
Bug 649435 - Remove the frozen date from the User Agent String
(& on & on & on)


Though I believe FF is more lax on /releases/ in that respect (some of the files are still dated 2010-01-01, but most are dated the release date), where SeaMonkey continues to have virtually ALL the files dated 2010-01-01 (omni.jar being one exception).

And that, at the very least for the releases, should be changed.

And even better if the whole 01-01-2010 deal were done away with altogether (IMveryHO).

Comment 2

[Robert Kaiser]

(In reply to comment #1)
> This is done purposely.

That statement is correct, but your reasoning isn't. This has nothing to do with Build IDs or the UA string, this is about file dates in the package. I don't know the exact reason any more, but it was some build stupidity of some packaging stuff.

Still, accounts to a WONTFIX for now.

Comment 3

[Rob Janssen]

Please fix it, it causes extra trouble in logon scripts that check file dates to update the program.

File modification dates should reflect the date of release (or commit for release), possibly with their time-of-day fixed to some single value.
File modification dates should not be set to artifical dates in the past or future.

Comment 4

[Philip Chee]

This is common build-config code used by Firefox, Thunderbird, SeaMonkey etc. It's part of the omnijar process. To have any chance of getting this fixed you need to file a bug somewhere in (guesses) Core::Build Config.

Comment 5

[Robert Kaiser]

(In reply to comment #3)
> Please fix it, it causes extra trouble in logon scripts that check file
> dates to update the program.

We don't support other update functionality than our internal automated update function and that doesn't need a change here. Please use that functionality.

Comment 6

[Rob Janssen]

That may be practical for the home user, but it is not feasible for a local network where users don't have administrative rights over their computers, and the systems are not supposed to track every update available on the internet, only acceptance-tested well-defined update steps.

Setting file modification dates to values way in the past, only because some broken build script requires it, is a bad bad thing.

Comment 7

[Robert Kaiser]

The SeaMonkey project doesn't have the manpower or other resources to support installs where the application cannot initiate updates by itself - and the issue you are complaining about is out of reach for the SeaMonkey project members in the first place. Sorry.

Comment 8

[skierpage]

Good news!  I think the Core:Build Config bug is Bug 600241 , whose fix was checked in 2011-05-23. FF 5 and SM 2.2b1 have 2010-01-01 file dates, but this bug appears fixed in recent SeaMonkey nightly builds:

% tar -tvjf seamonkey-2.4a1.en-US.linux-x86_64.tar.bz2 
  -rwxr-xr-x 0/0            7632 2011-06-27 07:36 seamonkey/libmozalloc.so
  -rwxr-xr-x 0/0           50464 2011-06-27 07:36 seamonkey/seamonkey-bin
  ...
  -rw-r--r-- 0/0         6412430 2011-06-27 07:37 seamonkey/omni.jar
  etc.

Files in the seamonkey/omni.jar archive are still dated 2010-01-01, I think that's intentional (bug 592369 ?).  Progress, thanks!

Comment 9

[therube]

Regression here, or something else that caused the dates to revert back to 01/01/2010 with 2.2b3?

Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110701 Firefox/5.0 SeaMonkey/2.2