Open Bug 663026 Opened 15 years ago Updated 4 years ago

Windows Indexing displays the wrong date

Categories

(Thunderbird :: OS Integration, defect)

x86
Windows 7
defect

Tracking

(Not tracked)

People

(Reporter: Colin.Enticott, Unassigned)

Details

(Whiteboard: [waiting sid])

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 The .wdseml files with the Windows Indexing integration have a modification date of the time the file was created. This does not match the user’s expectations as the content of the message has not been modified since the email was received by their email service. The most notable effect of this is when a user does a search for a keyword, the email files appear out of order. The user can then choose to sort on “received date”, but this is out of sync with the non-thunderbird results. There is no comparison method available to match received date with the modification date of the user’s other files. Reproducible: Always Steps to Reproduce: 1. Download an sync all email 2. Do a windows search for a keyword that appears in email and your local files 3. You cannot sort by the expected "modified date" of the email with local files. Actual Results: You cannot sort by the expected "modified date" of the email with local files. Expected Results: The results should be sorted by the expected "modified date" of the email along side the local files.
Version: unspecified → 3.1
(In reply to Colin from comment #0) > Expected Results: > The results should be sorted by the expected "modified date" of the email > along side the local files. sid0,is this realistic?
Whiteboard: [waiting sid]
Windows 7 has a "date received" column in Explorer which lets you do this. It's a bit inconvenient to use, though, and we could definitely fiddle around with the modified date with <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724933(v=vs.85).aspx>.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.