avi@pegasus.UUCP (02/17/87)
Thanks to Karl Kleinpaste, I have GNU emacs up on a 3B20 running SV_R2. I am using version 18.35. I have been laboring over the rmail package, by changing parts of the distribution to hard-code for /usr/mail/$LOGNAME, and have even manually inserted a "Mail: /usr/mail/avi" in the Babyl header of my RMAIL mailbox. None of this worked, but I was able to get it to find new mail in my ~/mbox by making it think that that was my mailbox source. I finally decided to try changing /usr/mail to be publicly writeable, and this fixed the problem nicely. Unfortunately, I don't think it is wise to leave /usr/mail writeable by just anyone. My guess (from looking at the ELISP) is that they are trying to remove my mailbox, and failing. If they just tried to zero it, they would suceed in emptying my mail box, and could go on and retrieve my mail. As it is, the package just tells me I have no new mail. The offending code is the C function Fdelete_file (AKA delete-file) in fileio.c that insists (quite legitimately) on being able to delete a file by unlinking it. I would prefer to not make myself the owner of /usr/mail or running as "root" or "mail" all the time. An obvious patch is to try to truncate a file when you can't delete it, but I am not sophisticated enough in ELISP to do that yet. Tony Hansen and I tried a fix in the condition-case exception handler, but that doesn't seem to have worked. Has anybody else fixed this yet, and how? I wonder if anybody is running this package who is not root! When I got my tar version from Karl, I couldn't even take it apart unless I was suid root. -=> Avi E. Gross @ AT&T Information Systems Laboratories (201) 576-6241 UUCP: suggested paths: [ihnp4, allegra, cbosg, rutgers, ...]!pegasus!avi -- -=> Avi E. Gross @ AT&T Information Systems Laboratories (201) 576-6241 UUCP: suggested paths: [ihnp4, allegra, cbosg, topaz, ...]!pegasus!avi ARPA: agross@ru-green
karl@osu-eddie.UUCP (02/17/87)
avi@pegasus.UUCP writes of problems getting GNU Emacs' rmail to find mail in /usr/mail/$LOGNAME. The best solution to this problem is to make $EMACS/etc/movemail setgid-mail. All movemail wants to do is pick up your mail file, and move it wholly elsewhere. It has to create locking files in order to obey /bin/mail's synchronization mechanism to avoid simultaneous updates. Anything which needs to create those locks must run setgid-mail. I do this on my machines, and it works fine. I read/write mail/news in GNU Emacs all the time; I haven't typed "mailx" at a shell prompt in a couple of months. The reason rmail says you have no new mail is that it ignores the diagnostic that movemail printed to stderr. The diagnostic correctly identifies the problem as an inability to create the lock. Try running movemail from a shell prompt; you'll see what I mean. >When I got my tar version from Karl, I couldn't even >take it apart unless I was suid root. Apologies. I created the distribution that I sent to a number of folks inside AT&T from my working area, which I have write-protected not for fascist reasons, but rather for simple paranoia against accidental destruction. The tar file I sent to several folks caused troubles when unpacked at the destination, and tar chown'd everything to uid 239. -- Karl
pdg@ihdev.UUCP (02/17/87)
In article <2939@pegasus.UUCP> avi@pegasus.UUCP (60021254-Avi E. Gross;LZ 3C-314;6241) writes: > >Thanks to Karl Kleinpaste, I have GNU emacs up on a 3B20 running SV_R2. Yes, thanks Karl.... (He provided it for my Vax). >[ Omitted long description of Rmail and /usr/mail problem ] >Has anybody else fixed this yet, and how? I wonder if anybody is running this >package who is not root! When I got my tar version from Karl, I couldn't even >take it apart unless I was suid root. The problem is not in the elisp code, but rather in the c program, movemail. Movemail tries to create a lock file in /usr/mail. It cannot do this on most systems and fails. The fix (I can mail it to you over datakit) is to move the lock file to /usr/tmp. A very simple fix. I have also rewritten part of the aliasing mechanism to do includes in alias files (common around AT&T). In regards to your other question: I did bring up all of GNUmacs without being root. That is how things should be. -- Paul Guthrie ihnp4!ihdev!pdg This Brain left intentionally blank.
trent@cit-vax.UUCP (02/17/87)
I don't know how effective this will be for others, but at our site (4.3 BSD vax Gnu 18.36) defining MAIL_USE_FLOCK solves the problem. (you should only have to recompile movemail with this defined) -- "Party until it hurts; then, party 'til it don't hurt no more." ../ray\.. (trent@csvax.caltech.edu, rat@caltech.bitnet, ...seismo!cit-vax!trent)
karl@osu-eddie.UUCP (02/18/87)
pdg@ihdev.UUCP writes: >The problem is not in the elisp code, but rather in the c program, >movemail. Movemail tries to create a lock file in /usr/mail. It >cannot do this on most systems and fails. The fix (I can mail it to >you over datakit) is to move the lock file to /usr/tmp. A very simple >fix. No, don't do that. /bin/mail defines a convention regarding the creation of lock files in /usr/mail. If you cause movemail to create locks in /usr/tmp, it will not be obeying the proper convention of the incumbent software. You will cause conflicts if mail arrives while movemail is pushing your mail around elsewhere. >I did bring up all of GNUmacs without being root. That is how things >should be. The problem wasn't that he had to be root to install it, it was that I botched the tar file sent to him (and you, I think) so that it had to be *unpacked* as root, unless you have an `o' option to tar to prevent chown'ing. -- Karl