After coming back from standby (or any other kind of network reconnect), until the connection to the server has been completely reestablished, the networking client (Netware or otherwise) fails the I/O calls, with the result that the OS kills the pmail process because the file handle for pmail.exe is now invalid.
Even when the OS does not kill the pmail process - say because pmail is installed locally - the application barfs because the mail (or mail folder) handles are dead and pmail doesn't have the logic to renew them. This is not something that can be done transparently. Each kind of file needs its own "recover from dead handle" logic.
While what I just mentioned is one way with which an app can recover from the server "going away", with the exception of standby/hibernate such an instance of a server "vanishing" should (ideally) never happen, and can (justifyably) not be taken into consideration. Pmail has however two real bugs that effectively make it incompatible with standby/hibernate.
- The first bug is that pmail is oblivious to shutdown/hibernate at all. The OS broadcasts a message when it is about to enter sleep/hibernate, but pmail ignores it. At a minimum, it should deal with a standby/hibernate message as if it received a "shut down" message, that is, pmail would tell the system not to proceed if such an event could lead to loss of data (eg unsent messages). Ideally however, pmail would save these unsent messages and allow the standby/hibernate to proceed normally.
- The second bug is pmail's poor implementation of the mailbox.lock hack. The hack is itself ok, a necessary stop-gap, but the way pmail implements it is poor. If this were properly implemented, pmail could (theoretically)
recover from any exception (e.g. a crash or an instance of a server "going away") without bothering the user with a question only answerable by the technologically savvy. If properly implemented, pmail wouldn't need to ask any questions at all. It would intrinsically know the answer.
The old David would take these observations to be a terrible affront. I think the new David knows that he has done a phenomenally good job but is nonetheless still human. :)
Cy
After coming back from standby (or any other kind of network reconnect), until the connection to the server has been completely reestablished, the networking client (Netware or otherwise) fails the I/O calls, with the result that the OS kills the pmail process because the file handle for pmail.exe is now invalid.<p>Even when the OS does not kill the pmail process - say because pmail is installed locally - the application barfs because the mail (or mail folder) handles are dead and pmail doesn't have the logic to renew them. This is not something that can be done transparently. Each kind of file needs its own "recover from dead handle" logic.</p><p>While what I just mentioned is one way with which an app can recover from the server "going away", with the exception of standby/hibernate such an instance of a server "vanishing" should (ideally) never happen, and can (justifyably) not be taken into consideration. Pmail has however two real bugs that effectively make it incompatible with standby/hibernate.</p><ol><li>The first bug is that pmail is oblivious to shutdown/hibernate at all. The OS broadcasts a message when it is about to enter sleep/hibernate, but pmail ignores it. At a minimum, it should deal with a standby/hibernate message as if it received a "shut down" message, that is, pmail would tell the system not to proceed if such an event could lead to loss of data (eg unsent messages). Ideally however, pmail would save these unsent messages and allow the standby/hibernate to proceed normally.
</li><li>The second bug is pmail's poor implementation of the mailbox.lock hack. The hack is itself ok, a necessary stop-gap, but the way pmail implements it is poor. If this were properly implemented, pmail could (theoretically)
recover from any exception (e.g. a crash or an instance of a server "going away") without bothering the user with a question only answerable by the technologically savvy. If properly implemented, pmail wouldn't need to ask any questions at all. It would intrinsically know the answer.</li></ol>The old David would take these observations to be a terrible affront. I think the new David knows that he has done a phenomenally good job but is nonetheless still human. :)
<p>Cy
&nbsp;</p>