neubauer@bsu-cs.bsu.edu (Paul Neubauer) (07/13/89)
In article <426@uncw.UUCP> session@uncw.UUCP (Zack Sessions) writes: +In article <114@egrunix.UUCP> steyaert@egrunix.UUCP (Terry Steyaert) writes: +>[trimmed] +>In Emacs, if there is no quota, emacs saves a nice zero length file, +>and tells the student there was a problem on save. What does this nice +>beginning computer student do but save again, and again. This puts +>multiple versions with zero lengths to them all. When the student decides +>to check his quota, notices it is low, and purges, what is he left with? +>Of course, the zero length files, and his program is gone. Now, as +>I see it, there are several options available. (More room per class +>isn't possible, so that is out.) +>[trimmed] + +I am unfamiliar with Emacs, but if it can run in a command file then why +not write yourself an 'envelope' command file for the students to run +by foreign command. It could prompt for the name of the file to edit, +save off the version number, run Emacs, after the user exits the editor, +check the new file created. Make sure it is the next version and that +its file size is not zero. If it is zero, it could do various things, +like automatic deletion, warning the user of its existance, showing +the user their current quota, etc. All this is doable with simple +F$ calls in DCL. + +As also mentioned, a version limit on the students directories is another +way to manage disk space. If you implement that, though, make sure your +users are aware of it! The problem with this suggestion, as with an earlier one that I just read is that the student sees the save-problem message while still WITHIN THE EDITOR and may save several times. As long as Emacs (I assume from the version # deleted from ZS's reply -- 3.8, i believe-- that this refers to MicroEmacs, rather than, e.g., GnuEmacs -- WHICH Emacs is usually an important question) saves a 0-length file then later versions are created. A version limit MIGHT (I'm not too sure of this) cause the previous good file to be eliminated in favor of the newer 0-length files. This might not be wholly bad, because IF that creates enough room to save the current version, then eventually it might get saved. HOWEVER, if the old version gets obsoleted, but the new version is enough larger than the old version, then the new version still might be too big to save and the student will still be left with no file. I know of no good solution that does not involve the source to (Micro?)Emacs. I am crossposting this discussion to comp.emacs, where it will probably be seen by Dan Lawrence, the author of MicroEmacs. (I have seen his postings there before, but I do not remember his email address, or I would simply forward your problem to him directly.) Assuming that the emacs under discussion IS MicroEmacs, this would be a rather serious bug. It should be noted, however, that MicroEmacs has had a couple of major revisions since 3.8. It is now up to 3.10. I have no idea whatsoever, whether Dan would have fixed this behavior in those versions. Good Luck (you may need it) -- Paul Neubauer neubauer@bsu-cs.bsu.edu neubauer@bsu-cs.UUCP <backbones>!{iuvax,pur-ee}!bsu-cs!neubauer
nwd@j.cc.purdue.edu (Daniel Lawrence) (07/13/89)
In article <8186@bsu-cs.bsu.edu> neubauer@bsu-cs.bsu.edu (Paul Neubauer) writes: >In article <426@uncw.UUCP> session@uncw.UUCP (Zack Sessions) writes: >+In article <114@egrunix.UUCP> steyaert@egrunix.UUCP (Terry Steyaert) writes: >+>[trimmed] >+>[He describes some problems with MicroEMACS 3.8 and VMS] >+>[trimmed] >+ >I know of no good solution that does not involve the source to >(Micro?)Emacs. I am crossposting this discussion to comp.emacs, where it >will probably be seen by Dan Lawrence, the author of MicroEmacs. (I have >seen his postings there before, but I do not remember his email address, or >I would simply forward your problem to him directly.) Assuming that the >emacs under discussion IS MicroEmacs, this would be a rather serious bug. >It should be noted, however, that MicroEmacs has had a couple of major >revisions since 3.8. It is now up to 3.10. I have no idea whatsoever, >whether Dan would have fixed this behavior in those versions. > Yes, 3.10b (and 3.9 as well), which again runs under VMS, does not have this problem. However there is some confusion, under VMS, concerning the new method MicroEMACS uses for "safe" saving.... ie EMACS opens up a temporary file, writes the buffer out, kills the old version, then renames the temp file to the old name. This makes saving very "safe" on other systems, but only succeeds in confusing VMS's version system. So under VMS in MicroEMACS version 3.10 and above add this line to your emacs.rc file: set $ssave FALSE Daniel Lawrence voice: (317) 742-5153 arpa: dan@midas.mgmt.purdue.edu The Programmer's Room Fido: 1:201/10 - (317) 742-5533