wls@astrovax.UUCP (William L. Sebok) (11/07/84)
There is something not very robust about the method of cancelling replies
from vnews (2.10.2). Supposedly if one exits from the editor without
editing the file it should cancel the reply. However there seems to be
a high probablility that the reply will get sent anyway. I have been
embarassed more than once by this (although as a superuser I have often
been able to zap it before it got out). This has happened when all I have
done is (from vi) immediately type ZZ to get out. It seems to happen most
often when one exits right away (like right after you have hit "r" by mistake).
I see from the code that the criteria for cancelling the reply is that
the modification time of the file be same after invoking the editor as
before. I can't really visualize right now why this would fail but
maybe it is due to 1 second time quantization (although it would seem
to me to be more likely to fail in the sense of erroneously cancelling
a reply).
Does anybody have any ideas? In case it makes any difference we are running
4.2 BSD. Perhaps the easiest thing to do would be to add another test like
cancelling the reply if the size of the edited file has not grown after the
editing. This would also be robust against a person starting to edit a reply
but deciding against it after having started it.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wlska@cbosgd.UUCP (Kenneth Almquist) (11/07/84)
> I see from the code that the criteria for cancelling the reply is that > the modification time of the file be same after invoking the editor as > before. I can't really visualize right now why this would fail but > maybe it is due to 1 second time quantization (although it would seem > to me to be more likely to fail in the sense of erroneously cancelling > a reply). > > Does anybody have any ideas? In case it makes any difference we are > running 4.2 BSD. In order to save on memory, System V and its predecessors do not include the modified time of a file in the in core copy of the inode. Instead the in core copy of the file simply has a flag which is set when the file is modified. When the inode is next written to disk, the modified flag on the in core copy of the inode is cleared and the modified time on the disk copy of the inode is set to current time, which of course is not necessarily the same as the time that the modified flag was set. I was a little surprised to read that the code also fails under 4.2 BSD since under 4.2 the in core copy of the inode does include the modified time of the file. However, a look at the 4.2 BSD code reveals that 4.2 BSD has a modified flag, and updates the modified time on an inode to the current time before writing the inode to disk when the modified flag is set. Perhaps the Berkeley people are more committed to being compatible with System V than we realized :-). The moral of all of this is, don't expect file modification times to be recorded down to the precise second. Using the file modification time would be a bad practice even if UN*X supported it because people tend to get in the habit of writing before they exit the editor even when they haven't made any changes. 2.11 vnews assumes that the user doesn't want to post a reply if 1) The file size is not changed, and 2) A checksum of the file is the same as when the file was written. Kenneth Almquist
stv@qantel.UUCP (Steve Vance@ex2499) (11/08/84)
>There is something not very robust about the method of cancelling replies >from vnews (2.10.2). Supposedly if one exits from the editor without >editing the file it should cancel the reply. However there seems to be >a high probablility that the reply will get sent anyway. I have experienced this, too. It happens maybe 7 out of ten times. I haven't been able to figure it out, either. I'm on a VAX with 4.2, just like Bill. >Perhaps the easiest thing to do would be to add another test like >cancelling the reply if the size of the edited file has not grown after the >editing. This would also be robust against a person starting to edit a reply >but deciding against it after having started it. How about a question for the human to answer, after the exit from the editor, like "Do you really, really want to send this?" or something. Seems like that would be easy to implement. I guess rn has this feature. -- Steve Vance {ucbvax,ihnp4,zehntel,onyx}!dual!qantel!stv Qantel Corporation, Hayward, CA
cem@intelca.UUCP (Chuck McManis) (11/08/84)
I always use :q! to abort a reply or a followup from vnews. It hasn't
failed yet.
--Chuck
--
-- Chuck - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\ All opinions expressed herein are my
{proper,idi}-> !intelca!cem own and not those of my employer, my
{ucbvax,hao}!hplabs/ friends, or my avocado plant. :-}
ARPAnet : "hplabs!intelca!cem"@Berkeleyrick@seismo.UUCP (Rick Adams) (11/08/84)
The problem with replys not being aborted is due to a missing fflush() immediately before the fstat() in the reply subroutine in visual.c ---rick
rcd@opus.UUCP (Dick Dunn) (11/13/84)
> >Perhaps the easiest thing to do would be to add another test like > >cancelling the reply if the size of the edited file has not grown after the > >editing. This would also be robust against a person starting to edit a reply > >but deciding against it after having started it. > > How about a question for the human to answer, after the exit from the > editor, like "Do you really, really want to send this?" or something. > Seems like that would be easy to implement. I guess rn has this feature. Ouch! How about not asking the user if he really wants to do what he just did? (It's bad enough when people ask stupid questions, but when machines start doing it...:-) 'Twould be better to get the test for "modified" correct than to ask the user to do it. And, by the way, the basis for the program checking further should be "file is the same size", not "file has not grown"! Some people are actually thoughtful enough to pare down the base note before adding the followup. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Never attribute to malice what can be adequately explained by stupidity.
dmmartindale@watcgl.UUCP (Dave Martindale) (11/15/84)
> And, by the way, the basis for > the program checking further should be "file is the same size", not "file > has not grown"! Some people are actually thoughtful enough to pare down > the base note before adding the followup. > -- > Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 Well, if you're going to look at file size, the criteria for throwing away the followup/reply probably should be "file is same size OR file is zero size", since some of us are used to deleting the contents of the editor buffer and writing it out when we don't want it sent after all, since that's what you had to do with 2.10.1.
wls@astrovax.UUCP (William L. Sebok) (11/21/84)
> > And, by the way, the basis for > > the program checking further should be "file is the same size", not "file > > has not grown"! Some people are actually thoughtful enough to pare down > > the base note before adding the followup. > > -- > > Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 > > Well, if you're going to look at file size, the criteria for throwing > away the followup/reply probably should be "file is same size OR file is > zero size", since some of us are used to deleting the contents of the > editor buffer and writing it out when we don't want it sent after all, > since that's what you had to do with 2.10.1. I think that that should be "file is same size OR file is zero size OR file is 1 byte" since some editors (like vi) will write out a single newline when one throws away the editor buffer. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls