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.
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
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
I'm not using Mozilla on Linux right now...
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
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
Last Resolved: 13 years ago → 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.