Last Comment Bug 362612 - Folder truncation fails when filtering on POP3 account
: Folder truncation fails when filtering on POP3 account
: verified1.8.1.1
Product: MailNews Core
Classification: Components
Component: Filters (show other bugs)
: 1.8 Branch
: x86 OS/2
-- normal with 1 vote (vote)
: ---
Assigned To: Peter Weilbacher
Depends on:
  Show dependency treegraph
Reported: 2006-12-02 16:24 PST by Peter Weilbacher
Modified: 2008-07-31 04:30 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

suggested fix (1.40 KB, patch)
2006-12-02 16:31 PST, Peter Weilbacher
mozilla: review+
Details | Diff | Splinter Review

Description User image Peter Weilbacher 2006-12-02 16:24:50 PST
As three people reported on the newsgroup, both SeaMonkey and Thunderbird from the 1.8 branch show the same problem with filtering. When a filter (especially the junk filter?) runs and moves a message away from the INBOX, the error message

   "There was an error truncating the Inbox after
    filtering a message to folder '<target folder>'.
    You may need to shutdown SeaMonkey and delete INBOX.msf."

is displayed.

I debugged this and the problem seems to be in nsFileSpec::Truncate() in xpcom\obsolete\nsFileSpecOS2.cpp. The DosOpen() there fails with an ERROR_SHARING_VIOLATION.

The problem seems to be that the Inbox file (this is the one involved, and not the INBOX.msf file as the error message suggests) is already opened (for reading) when SeaMonkey is started (checked using the psfiles OS/2 tool). When filtering, the file is truncated and so the code opened it using OPEN_SHARE_DENYREADWRITE. This always fails as it already is open (for reading). When changed to opening using OPEN_SHARE_DENYWRITE the problem is gone.

The questions are:
1. Why is the Inbox file already opened on startup and stays
   open afterwards?
2. What happens to the opened file when truncated and how with
   the open instance react to that?
3. How are other platforms handling this? From the non-response
   in the .seamonkey newsgroups, no problems exist there.

In my limited testing it didn't show a problem, but then I only made a POP3 account for testing and the problem doesn't show on my normal IMAP accounts.
Comment 1 User image Peter Weilbacher 2006-12-02 16:31:00 PST
Created attachment 247299 [details] [diff] [review]
suggested fix
Comment 2 User image Peter Weilbacher 2006-12-06 01:11:43 PST
Comment on attachment 247299 [details] [diff] [review]
suggested fix

OK, I got positive feedback on the test DLLs, requesting review.
Comment 3 User image Peter Weilbacher 2006-12-06 02:28:18 PST
Is one of you using SeaMonkey mail (or Thunderbird) from trunk and sees the same error there? If so, we probably have to make a similar change to xpcom/io/nsFileSpecOS2.cpp in addition to xpcom/obsolete/nsFileSpecOS2.cpp.
Comment 4 User image Dave Yeo 2006-12-06 12:32:01 PST
Using a couple of old Seamonkey trunk build and creating a test filter it seems to run with no problems, both on my inbox and for incoming mail.
All messages are moved and no errors of any kind
Comment 5 User image Andy Willis (abwillis) 2006-12-06 18:09:47 PST
I have been using filters on Trunk Seamonkey builds without any problems, junk and regular filters.  My current build is 11/28/06 and I haven't seen any failures with it or previously.
Comment 6 User image Mike Kaply [:mkaply] 2006-12-08 10:09:11 PST
Comment on attachment 247299 [details] [diff] [review]
suggested fix


We've had problems with file sharing in the past. Windows seems a lot moer lenient about opening files twice and things like that.
Comment 7 User image Peter Weilbacher 2006-12-09 04:38:30 PST
OK, thanks for the review. Checked into branch. (Fix is fully contained in OS/2-only file, so NPOTB policy applies and I don't wait for extra approval.)
Comment 8 User image Peter Weilbacher 2007-03-11 15:10:27 PDT
Verifying some older bugs.

(The complaints about this problem have definitely stopped, although this is just a workaround. See bug 321371 for further cross-platform work on this.)

Note You need to log in before you can comment on or make changes to this bug.