Closed Bug 250600 Opened 20 years ago Closed 16 years ago

summary files rebuilt due to Windows/Linux timezone discrepancy

Categories

(MailNews Core :: Database, defect)

Product:
MailNews Core
Component:
Database
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: eyalroz1, Unassigned)

Details

(Keywords: qawanted) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040626
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040626

I have recently arranged a dual-boot Windows / Linux setup for myself, and my
Mozilla profile under Linux has, instead of its Mail directory, a link to the
Windows profile's Mail directory. I can see the messages just fine, but the
problem is that whenever I switch OS (and open MailNews), the summary files for
each folder gets rebuilt. I am using builds from the last 10 days on both
platforms (although one of them is a nightly binary and the other one I built
from source), and there should not be any incompatibility between their
recognized formats for summary files.

Reproducible: Always
Steps to Reproduce:
It's not a difference in the format; it's a inconsistency in the timestamps of
the files, as reported by Linux and windows. We use the timestamps to know if
the summary file is valid, and Windows and Linux are not reporting the same
timestamps. When we compare the timestamp on disk vs what we've stored in the
db, they don't match.

You can try setting a hidden pref, user_pref("mail.db_timestamp_leeway", 10)
will set the leeway to 10 seconds, which might make it work for you (I'm not
sure how out of sync the time stamps are...)
I'll investigate the reason for the timestamp differences (I don't see why there
should be any, after all the clock is shared hardware and shouldn't differ
between Windows and Linux). But even if there is a timestamp difference,
shouldn't the check be of the mail folder's timestamp vs. the msf's timestamp?
And in that case, a timestamp difference between Windows and Linux should not
have an effect...
no, the .msf timestamp and the mailbox timestamp aren't/can't be guaranteed to
be the same - it's the timestamp we store *in* the .msf file that has to match
the timestamp of the local mail folder. 

We get the timestamp of the local mail folder.
We store it into the .msf file
Next time we open the db, we get the timestamp of the local folder again, and
compare it with the timestamp stored in the .msf file.
If they're different, we assume someone changed the local mail folder out from
under us.

Hope that makes sense.
Wouldn't it be more reasonable to set the timestamp of the msf file to that of
the mailbox? I mean, files already have timestamps without you having to write
the timestamp into them... if a timestamp is not written into the mail folder,
why write one into the msf?
Are you thinking that somehow the OS's are going to be consistent about the
inconsistent timestamps they report? I think storing a timestamp in the db is
perfectly reasonable - plus, it's conceivable that we could make changes to the
db that would affect the .msf file external OS timestamp w/o neccessarily
changing the timestamp of the local mail folder.
But if the external timestamp is untrustworthy for the msf file, why is it
trustworthy for the mail folder itself?
Windows timestamp:
(taken using Alt-Enter from explorer window)
Created:	Sunday July 11th 2004, 10:28:16
Modified:	Sunday July 11th 2004, 10:28:16


Linux, exact times:
sh-2.05b# ls --time=ctime --time-style=full-iso -la Drafts.msf
-rwxrwxrwx  1 eyalroz eyalroz 16588 2004-07-11 10:28:16.000000000 +0300 Drafts.msf
sh-2.05b# ls --time=atime --time-style=full-iso -la Drafts.msf
-rwxrwxrwx  1 eyalroz eyalroz 16588 2004-07-11 10:28:16.000000000 +0300 Drafts.msf
sh-2.05b# ls --time=use --time-style=full-iso -la Drafts.msf
-rwxrwxrwx  1 eyalroz eyalroz 16588 2004-07-11 10:28:16.000000000 +0300 Drafts.msf

But the summary files for Drafts.msf does get rebuilt. If anyone (=David) wishes
I could add my original & regenerated Drafts.msf to this bug as an attachment.
Did you try setting the leeway pref? If that helps, then the problem is what I
described...
Yes I have, and it had no effect. There's also the annoying related UI bug: the
status bar text "creating summary file for folder XYZ" sometimes does not
appear, or disappears almost immediately, while the progress bar sometimes shows
partial progress whether a summary file is recreated or not, so you are
disoriented into not knowing whether you've opened an empty folder or you're
waiting for the summary file.
If setting the leeway didn't help (I'm guessing you set it to 10 seconds as I
suggested), then perhaps the timestamp as reported by stat is wildly different -
maybe because of a timezone or daylight savings time difference - you could try
setting the leeway to an hour + 1 second - 3601 seconds
Yes, this seems to do the trick. What happens is that on Windows,
Israel/Palestine's default timezone is GMT + 2, and on Fedora Core 2 (probably
on most other distributions) the timezone is GMT + 3 (we have a daylight saving
time scheme). So although the local time of the files is reported as same, their
UTC time is seen as different.

Now, I'm sure you'll suggest I get the timezones in sync (which I should), but I
still submit that discrepancies should match, i.e. if MainNews thinks the .msf
is from an hour earlier of its real modification time, it should also consider
the mail folder to be from an hour earlier.

Note also that some people may be accessing their mail folders remotely, from
different machines, in which the local time is key correct but the timezone is
not (very frequent phenomenon, at least around these parts; when the DST ends,
few people update their timezone, and the rest update the time).
Severity: normal → trivial
Summary: summary files built in Linux not recognized in Windows and vice-versa → summary files rebuilt due to Windows/Linux timezone discrepancy
> MainNews thinks the .msf
>is from an hour earlier of its real modification time, it should also consider
>the mail folder to be from an hour earlier.

As I've explained before, MailNews does not care a fig about what the msf file
modification time is. All it cares about is the modification time of the local
mail folder. It happens to store this modification time in the .msf file. If we
stored it in a separate global database, e.g., panacea.dat, then perhaps this
would be clearer...or a little side text file...

And as I said before, there's no reason the timestamp of the .msf file and the
local mail folder should be the same, and that has nothing to do with
untrustworthiness - it has to do with the fact that the .msf file and the local
mail folder can get modified separately by Mozilla for perfectly valid reasons,
and ensuring that the .msf file's timestamp matches the local mail folder
timestamp is not something the code does. Right now, whenever the local mail
folder timestamp changes, we make sure this is stored in the .msf file. What you
would have us do is whenever the local folder time stamp is changed, update the
timestamp of the .msf file, and whenever the .msf file is changed, make sure its
time stamp is artificially changed to be that of the local folder - that's an
extra level of complication that I don't want to deal with.
Ok, it seems I misunderstood. Let's forget about the modification time

So what's being done is a comparison of the timestamp written into the msf, and
the modification time of the mail folder as reported by the operating system.

(scratches head) is there any way to obtain the file modification time not
corrected by timezone, but rather the actual time value which appears alongside
the file in the filesystem, physically? If that were possible, than it would
also be possible to authoritatively check, at startup, whether the the mail
folder was updated after the msf or not.
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
I'm not using Mozilla on Linux right now...
Status: RESOLVED → UNCONFIRMED
Keywords: qawanted
Resolution: EXPIRED → ---
QA Contact: database
Product: Core → MailNews Core
I haven't heard complaints about this in quite a while - we've changed the leeway to an hour, which should deal with small timezone differences. Marking wfm.
Assignee: bienvenu → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.