From: klh@panix.com (Ken Harrenstien) Newsgroups: alt.sys.pdp10 Subject: MM+CCMD (was Re: command-line completion) Date: 13 Feb 2002 01:42:51 -0500 Organization: PANIX Public Access Internet and UNIX, NYC Lines: 65 Message-ID: References: NNTP-Posting-Host: panix2.panix.com X-Trace: news.panix.com 1013582572 13968 166.84.1.2 (13 Feb 2002 06:42:52 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: 13 Feb 2002 06:42:52 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!panix!panix2.panix.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:10318 In article , Frank da Cruz wrote: >Gee, maybe it's time to gather up all the pieces and put it back together. >At Columbia, CCMD got the Y2K and y2K+1 patches (announced here) and that >was about the end of it. Would love to send my stuff in, at least. Note that the code is still copyrighted by Columbia and the notice says nothing about modification. If no one there has time to maintain it, perhaps you could spare a few cycles to get it GPL'd (or free-forked, etc) so that aspect doesn't hinder possible development or distribution by others. >Meanwhile I still use MM, as do other survivors from the DEC-20 era. >Recently Columbia migrated its user file system to humongous NFS servers, >and now we are all faced with the "NFS bug": Edit a message in EMACS under >MM, save the message in EMACS, exit EMACS, return to MM, find the result >truncated, sometimes partially, sometimes totally. EMACS has told Unix >(Solaris in this case, but it also happens elsewhere) to save the file and >then exits. Does EMACS do an fsync()? (I don't know.) In any case, since >this is an NFS disk, the file is written when Unix feels like getting >around to it AND when NFS feels like getting around to it, if ever, and MM >often reads it back before it is fully written. Hmmm. Have used MM+EMACS on NFS configs and seen this on other places, but can't recall it ever happening on Panix, which uses NetBSD NFS servers. >The problem is alleviated somewhat if you add a pause to MM at the point >where it gets control back from EMACS but before it reads in the temp file. >But since there is no way of knowing how long the pause must be, it can >(and does) still fail, no matter what you choose. > >On "bad NFS days", you can lose one message after another this way, so >I started adding code to MM to try to catch the situation and fix it, but >so far have not succeeded (it's only a spare time project and I don't have >any). I know Mark says NFS and Pine just don't mix and maybe the same is >true of MM and nothing can be done about it. You could try making it use temporary edit files on /tmp or /var/tmp, which normally are non-NFS dirs and have the 1000 ("sticky") mode bit set so only owners can delete/rename files therein. I don't remember if this still applies to Solaris though. At any rate, clearly this is fixable by conspiracy, with sufficient motivation; unfortunately I'm not an expert on elisp but I gather you can do just about anything with it, which presumably would extend to doing pipe or socket I/O. As an interesting note, the original PDP-10 EMACS (actually TECO) maintains its buffer pointers in a specific block pointed to by AC 2, precisely so superior processes are able to read out the contents directly from memory. This is how the QMAIL program snarfs things back on ITS; I don't remember if MM does the same thing on TOPS-20. >Once this is fixed, my list for MM includes: [...] >Actually I have much longer list but will probably never get to it so no >point including it. You never know. Now I'm wondering how many other MM users still exist, whether because they prefer the UI or because they want old mail files to remain accessible. --Ken ###### From: fdc@columbia.edu (Frank da Cruz) Newsgroups: alt.sys.pdp10 Subject: Re: MM+CCMD (was Re: command-line completion) Date: 13 Feb 2002 10:55:14 -0500 Organization: Columbia University Lines: 69 Message-ID: References: NNTP-Posting-Host: watsol.cc.columbia.edu X-Trace: newsmaster.cc.columbia.edu 1013615716 29461 128.59.39.139 (13 Feb 2002 15:55:16 GMT) X-Complaints-To: postmaster@columbia.edu NNTP-Posting-Date: 13 Feb 2002 15:55:16 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!feedme.news.mediaways.net!diablo.netcom.net.uk!netcom.net.uk!cpk-news-hub1.bbnplanet.com!news.gtei.net!dca6-feed1.news.digex.net!jfk3-feed1.news.digex.net!intermedia!panix!newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:10322 In article , Ken Harrenstien wrote: : In article , : Frank da Cruz wrote: : : >Gee, maybe it's time to gather up all the pieces and put it back together. : >At Columbia, CCMD got the Y2K and y2K+1 patches (announced here) and that : >was about the end of it. : : Would love to send my stuff in, at least. Note that the code is still : copyrighted by Columbia and the notice says nothing about : modification. : Don't worry about the copyright -- it's just a copy of the original Kermit copyright. Modifications and fixes gratefully accepted, just as they always have been with Kermit; just send 'em to me. [MM+EMACS NFS truncating problem...] : You could try making it use temporary edit files on /tmp or /var/tmp, : which normally are non-NFS dirs and have the 1000 ("sticky") mode bit : set so only owners can delete/rename files therein. I don't remember : if this still applies to Solaris though. : Right, this is one of the ideas on my list for next time I have a chance to work on this. I'm not sure I'm comfortable putting personal, possibly senstive email in /tmp, but no doubt that's just paranoia. Another is to simply not delete temp files -- but then there needs to be a way to refresh the current message from them in case the first time you read them in, they are incomplete. Also there needs to be a way to manage them. Currently they are named with the pid, but we'd have to extend that to pid + serial number or somesuch, and then delete them all upon exit. Many other possibilities exist... : At any rate, clearly this is fixable by conspiracy, with sufficient : motivation; unfortunately I'm not an expert on elisp but I gather you : can do just about anything with it, which presumably would extend to : doing pipe or socket I/O. : It should be fixable or at least work-around-able in MM itself. However, if EMACS does not do all in its power to flush saved files out to disk, that should be fixed too, but who fixes EMACS? But since the real problem is NFS, maybe there is no good solution except not to use NFS. : >Once this is fixed, my list for MM includes: : [...] : >Actually I have much longer list but will probably never get to it so no : >point including it. : : You never know. Now I'm wondering how many other MM users still : exist, whether because they prefer the UI or because they want old : mail files to remain accessible. : For the record, I use MM for its user interface and functionality. It does everything I want (with a few exceptions, mainly character-set stuff), and it does not insult me with desktop metaphors ("My Favorite New Mail Folder" etc). It totally ignores enclosures, which is exactly what I want a mail client to do. Most important, it does not make me take my hands away from the home keys. I'm a fast touch typer, and I mightily resent any application that does not let me go at full speed. I realize I'm a niche market :-) There are perhaps as many as 100 other MM users at Columbia. At this point, sad to say, I think I'm the MM maintainer. Sad only because I don't have the time to do it. Anybody who's interested in helping out, let me know and I'll make my current source available. - Frank ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: alt.sys.pdp10 Subject: Re: MM+CCMD (was Re: command-line completion) Date: 13 Feb 2002 20:53:56 +0100 Organization: My own Private Self Lines: 67 Message-ID: <6u1yfpupij.fsf@chonsp.franklin.ch> References: NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1013630036 1205 10.0.3.2 (13 Feb 2002 19:53:56 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 13 Feb 2002 19:53:56 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch alt.sys.pdp10:10330 fdc@columbia.edu (Frank da Cruz) writes: > In article , > Ken Harrenstien wrote: > : > : You could try making it use temporary edit files on /tmp or /var/tmp, > : which normally are non-NFS dirs and have the 1000 ("sticky") mode bit > : set so only owners can delete/rename files therein. I don't remember > : if this still applies to Solaris though. root.murnau:/root 2> uname -a SunOS murnau 5.6 Generic_105181-29 sun4u sparc SUNW,Ultra-2 root.murnau:/root 3> la /tmp total 337 drwxrwxrwt 4 sys sys 442 Feb 13 20:23 ./ drwxr-xr-x 26 root root 1024 Nov 15 15:06 ../ Was still so in Solaris 2.6. I doubt it has changed in standard install. But it is removed on security concious sites (and all other sticky directories). > to work on this. I'm not sure I'm comfortable putting personal, possibly > senstive email in /tmp, but no doubt that's just paranoia. Generally one should be getting rid of /tmp anyway. Anything that requires an directory with the sticky bit is a security hole waiting to happen. Problem: malicious user does ln -s /etc/passwd /tmp/whatever then root uses an program that is known to write to /tmp/whatever. Instant broken user database. Or with different link any other root-only-writable file shot. Not to mention, that any modern Unix program should prefer $TMP to hardcoded /tmp. and $TMP is intended to be set to ~/.tmp/ or so, which will end up back on NFS. > Currently they are named with the pid, but we'd have to extend that to pid + > serial number or somesuch, and then delete them all upon exit. Use the Message-ID: field? > It should be fixable or at least work-around-able in MM itself. However, > if EMACS does not do all in its power to flush saved files out to disk, > that should be fixed too, but who fixes EMACS? The FSF owns it. Their website www.gnu.org surely lists maintainers for each program. > But since the real problem > is NFS, maybe there is no good solution except not to use NFS. Must be Solaris NFS client. The NFS protocol specifies that the server should only report back after it has flushed. One reason NFS is so slow. Perhaps Solaris client (or even your NFS server) has an "fix" for that, that does not wait for confirmation, which some "helpfull" admin has switched on. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual Robbery