cudep@warwick.ac.uk (Ian Dickinson) (10/17/90)
I have problem with ELM 2.3 PL8 (Sun 3/50 SunOS 4.1 - mbox NFS mounted) A series of messages were being delivered to my mbox, whilst I happened to be reading mail. This mean elm went through its standard six attempts to acquire the mbox.lock. After it failed to get the lock, it exited. This meant that the 300+ messages I had marked as deleted never got deleted at all. Surely, the correct behaviour is give up for some time, and try later, whilst allowing the user to continue reading the mail elm has already loaded up? I admit there is problem when it comes to actually leaving elm, since it can't rewrite the mbox without a lock. But should it behave like this when only trying to READ an mbox? Thanks, -- \/ato. Ian Dickinson. GNU's feelin' horny. Kunst und Wahnsinn. vato@cu.warwick.ac.uk Sabeq. Mind the gap! vato@tardis.cs.ed.ac.uk gdd046@cck.cov.ac.uk "I know what you sell - I don't want to buy!"
syd@DSI.COM (Syd Weinstein) (10/18/90)
cudep@warwick.ac.uk (Ian Dickinson) writes: >I have problem with ELM 2.3 PL8 (Sun 3/50 SunOS 4.1 - mbox NFS mounted) >A series of messages were being delivered to my mbox, whilst I happened >to be reading mail. This mean elm went through its standard six attempts >to acquire the mbox.lock. After it failed to get the lock, it exited. >This meant that the 300+ messages I had marked as deleted never got >deleted at all. Surely, the correct behaviour is give up for some time, >and try later, whilst allowing the user to continue reading the mail >elm has already loaded up? I admit there is problem when it comes to >actually leaving elm, since it can't rewrite the mbox without a lock. >But should it behave like this when only trying to READ an mbox? Ok, there are several schools of thought here. Elm takes six tries, several seconds apart, the total attempt is about a minute. If Elm cannot lock the mailbox in a minute, something major is wrong. Thus get out and let the user figure it out, he has more knowledge then we do. Thats the approach Elm takes by default behavoir. It doesn't try to figure out whether or not it really could continue, it just says my world is not correct, get out and let betters solve it. I don't understand why the mailbox stayed locked so long. However, if that is common on your net, you need to increase the timeout. Elm uses the same code to always get and deal with the mailbox, so it doesn't know you could continue and try the add later, it just knows it couldn't get the lock. Actually if it did continue in that case, and just delay the add, it would still run into trouble on a resync or a close of the mailbox, what should it do then? I think the current answer is as best as we can do at the present. Let Elm not second guess the system and flag to call in the guru's when the world is not right. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
cudep@warwick.ac.uk (Ian Dickinson) (10/25/90)
In article <1990Oct18.151058.21885@DSI.COM> syd@DSI.COM writes: >Ok, there are several schools of thought here. Elm takes six tries, >several seconds apart, the total attempt is about a minute. If Elm >cannot lock the mailbox in a minute, something major is wrong. Thus >get out and let the user figure it out, he has more knowledge then we do. > >I don't understand why the mailbox stayed locked so long. However, >if that is common on your net, you need to increase the timeout. It is not common - I just happened to getting a barrage of mail from usenet software whilst reading my mbox. Not big messages - just lots of small ones. >Elm uses the same code to always get and deal with the mailbox, so it >doesn't know you could continue and try the add later, it just knows >it couldn't get the lock. Actually if it did continue in that case, >and just delay the add, it would still run into trouble on a resync or >a close of the mailbox, what should it do then? On exit the current behaviour is about as good as we could expect really. >I think the current answer is as best as we can do at the present. I think it is mostly right. It would be nice for it to ask before exiting though, so you could wait and try again later. Thanks, -- \/ato. Ian Dickinson. GNU's feelin' horny. Kunst und Wahnsinn. vato@warwick.ac.uk Sabeq. Mind the gap! vato@tardis.cs.ed.ac.uk gdd046@cck.cov.ac.uk "I know what you sell - I don't want to buy!"