da@cs.brown.edu (David Ascher) (03/07/91)
This isn't particularly mac relevant, but lots of readers of this newsgroup would probably like to hear about it. If you don't use Eudora or some other POP3 client, and if you don't use popper as your POP3 server, you probably should skip to the next article... Ok, now that i have the interested parties only... The Berkeley popper server is a great piece of software, simple, well written, etc. BUT, there appears to be a bug which could be a real problem. When downloading a set of messages from the Unix server to the Mac, if for some reason or other the TCP connection dies, the unix server loses all the mail that was in the user's mailbox. This can be replicated with a simple telnet session, so it's not a Eudora problem at all. If anyone has any ideas on how to modify the server to solve this problem, please let it be known -- there are lots of users out there who will not be happy to lose all their incoming mail because of a network problem or a power failure... --david ascher ---------- da@cs.brown.edu (Internet) uunet!brunix!da (uucp) da@browncs.bitnet (bitnet) Box 3209, Brown University, Providence RI 02912 -- (1) (401) 863-4348
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/08/91)
In article <67594@brunix.UUCP> da@cs.brown.edu (David Ascher) writes: >[Discussing popper] >problem. When downloading a set of messages from the Unix server to >the Mac, if for some reason or other the TCP connection dies, the unix >server loses all the mail that was in the user's mailbox. This can be >replicated with a simple telnet session, so it's not a Eudora problem >at all. This is a bit extreme. *I* cannot replicate the problem using telnet (and have never seen it using Eudora), so I can confidently say that "if your network connection dies during a popper session, you will lose your mail" is too sweeping a statement. David, please tell us what version of popper you are using, and what the recipe is for replicating the problem. Only then is anybody likely to give you suggestions for a fix. (For the record, I'm running 1.7b4. I logged into popper, did an retr on a BIG message, and pulled the terminator from my ethernet segment. The transfer stopped (of course), popper exitted (eventually), but the mail was left intact.) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
da@cs.brown.edu (David Ascher) (03/09/91)
In article <1991Mar8.142343.8493@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >[Discussing popper] This is a bit extreme. *I* cannot replicate the problem using telnet (and have never seen it using Eudora), so I can confidently say that "if your network connection dies during a popper session, you will lose your mail" is too sweeping a statement. David, please tell us what version of popper you are using, and what the recipe is for replicating the problem. Only then is anybody likely to give you suggestions for a fix. (For the record, I'm running 1.7b4. I logged into popper, did an retr on a BIG message, and pulled the terminator from my ethernet segment. The transfer stopped (of course), popper exitted (eventually), but the mail was left intact.) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Well, I love a challenge. =) No, seriously. I simulated the problem again, since I wanted to make sure... Here's my test setup: I send two pieces of mail to a test user. Then, from the server itself, i telnet to popper, user, pass, retr 1. While the message is being sent to the screen, I reboot the mac. Drastic, but effective. When I telnet to popper again, the user has no messages left. This was first brought to my attention when someone lost 40 mail messages at once. Now, I have heard from at least one other person who had this problem. I am using popper v. 1.7 (no Betas in the version.h file), on a Decstation 5000/200 running Ultrix v4.1. This problem also occurs on a Sun Sparc 1 runnning SunOS v4.1. It may be a good idea for people to try out the above test on their machines and let me know if the problem occurs/doesn't occur. I thought that this was a software bug with popper (i.e., it doesn't handle the loss of a connection well), but maybe it is socket-implementation dependent, or even worse, file-system dependent (i.e. what happens to a file which is never "close()"d...) . If people send me their test results, I will compile them and post a summary. Maybe my version of popper is outdated. The SccsId has a date of 7/13/90 in the popper.c file. I will look at the code more carefully and try and understand what is supposed to happen. It's well written so that should be easy. Anyone else please feel free and help out. -- -- David Ascher -- Lead/Sr. Systems Programmer (UNIX) Computing and Information Services Brown University, Providence RI 02912 Internet: dascher@brownvm.Brown.EDU (Internet) UUCP: uunet!brunix!da Bitnet: dascher@brownvm
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/09/91)
YIKES! He's right. Popper 1.7 will lose mail if your network connection goes down. Popper 1.7b4 (the older, beta version I run) will not. I guess it pays to be lazy. I have asked Berkeley to withdraw 1.7 in favor of 1.7b4 until the problem can be fixed, or else to allow me to redistribute 1.7b4. I'll post a note to this group when I get a response. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
sanders@parc.xerox.com (Rex Sanders) (03/09/91)
Steve Dorner writes: >YIKES! He's right. > >Popper 1.7 will lose mail if your network connection goes down. I've seen something like this before. Look in your mail spool directory (typically /usr/spool/mail or /var/spool/mail) for a file named something like ".popUSERNAME" where USERNAME is your Unix login name. Apparently, under some conditions, the temp file popper uses doesn't get renamed back to your old mailbox name. All your old mail is still in this temp file. -- Rex
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/14/91)
I give up. No response out of Berkeley, so... You can all have my version of popper, which is a slightly hacked 1.7b4. Anonymous ftp to pequod.cso.uiuc.edu, and get pub/popper1.7b4.tar.Z. If you are running popper version 1.6, YOU NEED THIS POPPER. If you are running popper version 1.7 (actually, 1.7b5 or later), YOU NEED THIS POPPER. Version 1.6 can corrupt maildrops, and 1.7b5 and later will very happily lose all your mail if anything goes wrong during a network connection. (UNIX gurus may be able to get it back from /usr/spool/mail/.popYOURLOGIN). I have had NO problems with popper1.7b4. Yes, I know I'm probably violating some copyright. I wouldn't do it if the bugs were not so serious, and I will withdraw this version of popper as soon as Berkeley puts a fixed version on their server. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
cliff@garnet.berkeley.edu (Cliff Frost) (03/21/91)
The problem with popper reported here last week is real, and serious. It appears to have been introduced into popper around September, 1990. It would occur if you had compiled popper with -DDEBUG, and then run popper without the "-d" (debug) flag. If you compiled popper without -DDEBUG then you are not vulnerable to this particular bug. Unfortunately, the Makefile in the popper-1.7.tar.Z file has -DDEBUG set as the default. I have changed the default in the makefile in popper-1.7.tar.Z in the ftp repository. There is also a popper-1.81beta.tar.Z there which fixes two other problems. I believe 1.81 is stable, but will wait for some time before removing the 1.7 file. The ftp repository is ftp.CC.Berkeley.EDU. Its current addresses are: 128.32.136.9, 128.32.206.9, 128.32.206.12, 128.32.136.38. Many thanks to Steve Dorner and others who pointed this out to us. Cliff Frost UC Berkeley