12850 - We need to bring over folder locks from 4.5

Status: RESOLVED INVALID

(MailNews Core :: Backend, defect, P4)

Description

[Scott MacGregor]

In 4.5 we had locks on each berkley mail folder. These locks prevented
multiple instances of the code from reading/writing into the same berkley mail
folder at the same time. We need to port this code into 5.0 as we don't have it
right now. Without this code, it is possible to run into the following
scenario:
    downloading new mail for a pop account which involves writing the messages
    into your berkley mail folder (your inbox)

    At the same time, you try to display a message in your inbox. This involves
    reading out of the same file we are trying to write new messages into.

Bad things can happen in this scenario. This is part of what may have happend to
Kat in Bug #11895. I'm just pulling it out into a separate bug.

We can hang the folder locks off the mail session or possibly off the particular
server which I believe has a list of all the subfolders in it.

Comment 1

[Scott MacGregor]

Accepting. M11.

Comment 2

[lchiang]

http://slip/projects/seamonkey/mail-QA-beta1-status.html

Comment 3

[lchiang]

I was not paying attention yesterday - please ignore my previous comment.  I
pasted in the wrong text.

Comment 4

[lchiang]

mscott - do you think this should be a dogfood bug as more people are going to
use mail?

Comment 5

[Phil Peterson]

Not holding M11 for this

Comment 6

[Matthew Tuck [:CodeMachine]]

Is this inbox lock going to be held throughout a POP download?  Or released
regularly so you can still read the inbox (with degraded performance due to lock
blocking)?

Comment 7

[Phil Peterson]

matty, in 4.x it was a write lock. You could have as many concurrent readers as
you want, but only one writer for as long as one operation (like POP download)
needed the write state to be consistent.

With respect to the performance question, we didn't keep multiple write requests
waiting in a queue -- we just turned them away, saying "come back later" or
something. So no performance degradation.

Comment 8

[leger]

Putting on PDT+ radar for beta1.

Comment 9

[Matthew Tuck [:CodeMachine]]

OK, you can have an appender while people are reading, makes sense.

I recall Win 4.x being OK in this area, but Linux 4.x prevents me from reading
msgs in the folder I had selected at the time of POP download initiation. 
Workaround is to switch to another folder and back.  I'm presuming here that
that's a lock problem.  No longer a problem?

Comment 10

[Scott MacGregor]

I'd nominate this bug for the early PDT+ cut award....Clearing the resolution so
PDT team can re-evaluate tomorrow when they begin cutting PDT bugs

Comment 11

[Scott MacGregor]

Moving my remaining M14 bugs to M15 which is the next targeted milestone.

Comment 12

[selmer (gone)]

Since this bug is marked P4, moving to M17.  If you disagree, please let me know.

Comment 13

[selmer (gone)]

Mail Review recommends beta2 stopper.  Adding nsbeta2 keyword.

Comment 14

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.

Comment 15

[leger]

Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.

Comment 16

[Jim Roskind]

6/15 has passed... so I'm cleaning up the whiteboard and markeing beta2 minus.
The potential for corruption of a mail folders is a Real Bad Thing (TM), and 
hence I'm nominating for beta3.

Comment 17

[Jim Roskind]

... but as a side comment... I would have guessed that a "read" of a message 
from the POP server would amount to an append to a file, which would not 
significantly conflict with an effort to display a message.  Unless I'm missing 
the point, the only problem that would really appear would have to surround the 
deletion (or marking for deletion?) of a message, in such a way that the file 
size changed, *while* an attempt was made to appeand (or do a second write 
operation).  If I'm understanding, then the *critical* locking is between all 
write operations (includes delete, and append), and a less critical (?) bug 
involves getting locking on all read operations tied in.  Corruption can result 
from multiple read ops, but only a "seemingly trashed" message can result from 
failing to lock on a read.

Since I read the bug, I thought I'd toss in my 2 cents about what seemed more 
crucial... but not being a berkely mail folder expert... I could be way off.

Caveat Fixor.

Comment 18

[scottputterman]

for some reason beta1 keywords are turning into nsbeta1. removing it to not
cause confusion.

Comment 19

[Oliver Klee]

Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.

Comment 20

[lchiang]

general profile locking bug for product is 
http://bugzilla.mozilla.org/show_bug.cgi?id=76431.

Comment 21

[(not reading, please use [e-mail] instead)]

bienvenu, mscott thought that you might have implemented this, but all I could 
find was the stuff you did for folder locking and compacting.

Comment 22

[Wayne Mery (:wsmwk)]

bienvenu says "nah" to this still being relevant to current mail infrastructure, so closing invalid.

Comment 23

[David :Bienvenu]

we have folder semaphores in Thunderbird - we don't have external locks; we count on profile mgr locking to prevent multiple apps from accesssing the same folder