[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs c-X c-W doesn't increment the "number of writes to...



The floowing patch, distributed recently on TOPS20, is probably
what you'all need to fix this problem...

	
Date: Sun, 14 Oct 1984  12:02 EDT
From: "Leonard N. Zubkoff" <Zubkoff@TL-20B.ARPA>
To:   Tops-20@SU-SCORE.ARPA
Subject: Bug in Rnamf%

There is a bug in Rnamf% which can cause a file not to be incrementally dumped
by DUMPER.  When a disk file is renamed on top of an existing disk file,
thereby destroying the existing file, the .FBCNT word of the renamed file is
taken from the source file but the .FBBK0 word is taken from the existing file.
Note that this problem is obscure but does occur - the MacLisp compiler, for
example, opens a temporary output file and then renames it to be the correct
file, preserving the generation number from the source file; EMACS also can
tickle this if a file is written back to the same generation number, as it used
the same temporary output file renaming trick (BABYL files for example).  The
fix I applied is to change DSKREN to always zero the .FBBKn words of the
resulting file:

;UPDATE .FBCRE WORD IN FDB

	CALL UPDDTM		;GET CURRENT TIME IN A
	MOVE B,A		;COPY TO B
	MOVE A,DSTFDB		;GET DESTINATION FDB ADDRESS
	SKIPL B			;CURRENT DATE AND TIME KNOWN?
	STOR B,FBCRE,(A)	;YES, STORE INTO FDB

	SETZM .FBBK0(A)		;TL5 Set .FBBK0 to 0
	SETZM .FBBK1(A)		;TL5 Set .FBBK1 to 0
	SETZM .FBBK2(A)		;TL5 Set .FBBK2 to 0

	MOVE D,DIRORA		;GET ADR OF DIR AREA
	-----------------