reopen 306892 thanks Bug 306892 still happens for me, running frm from mailutils 1:0.6.90-2 on powerpc.
It does not crash on every mailbox, but on a great many. The bug of leaving behind lock files is also there. Please fix this regardless. In addition, once the lock file is left behind, further invocations of frm cannot deal. Please make the lock file not behave this way: if the program which created it is no longer running, it shouldn't be honored. In addition, once there is a spooged lockfile, the --lock-expire-timeout and relate flags do not seem to avail anything to cause it to be ignored. In addition, frm shouldn't need to lock the mail file in the first place. So that's a total of five bugs: 1) I still see segfaults on most of my mailboxes. Presumably they happen as a result of horridly formatted or otherwise bogus spam that ends up in the mailbox. 2) Any program that creates lock files should clean them up when receiving a signal by installing a proper signal handler which deals properly. 3) Any program that depends on lock files should use a mechanism that does not hose things if the program or the system crashes unexpectedly. 4) Any program that depends on lock files should provide *working* options that override them under user control. 5) Programs that merely read data files for informational purposes have no business creating lockfiles in the first place. Would you like me to submit separate bugs, or leave this one to stand for all of them? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
