3.730 NB with large files (131)
Willard McCarty (MCCARTY@vm.epas.utoronto.ca)
Fri, 10 Nov 89 22:08:22 EST
Humanist Discussion Group, Vol. 3, No. 730. Friday, 10 Nov 1989.
(1) Date: Wed, 8 Nov 89 15:01 EST (10 lines)
From: <FLOOD@IUBACS>
Subject: NotaBene3 bug
(2) Date: Wed, 08 Nov 89 19:37:42 EST (16 lines)
From: Norman Zacour <ZACOUR@vm.epas.utoronto.ca>
Subject: NB bug?
(3) Date: Thu, 9 Nov 89 00:56:19 EST (10 lines)
From: Itamar Even-Zohar <B10@TAUNIVM>
Subject: Re: 3.720 bug in Nota Bene (62)
(4) Date: Fri, 10 Nov 89 15:39 CDT (34 lines)
From: LAVENDA@MSUS1.BITNET
Subject: Bug in Nota Bene or Disk Nearly Full?
(5) Date: 10 November 1989 (28 lines)
From: Willard McCarty <MCCARTY@vm.epas.utoronto.ca>
Subject: NB ?bug ?feature
(1) --------------------------------------------------------------------
Date: Wed, 8 Nov 89 15:01 EST
From: <FLOOD@IUBACS>
Subject: NotaBene3 bug
The NotaBene bitnet board has had several reports of errors in
handling _large_ files. Their conclusion was simply to divide
your files into smaller segments, then NotaBene won't throw
a fit. But I believe Dragonfly have been told about it.
John Flood, Indiana University (FLOOD@IUBACS)
(2) --------------------------------------------------------------24----
Date: Wed, 08 Nov 89 19:37:42 EST
From: Norman Zacour <ZACOUR@vm.epas.utoronto.ca>
Subject: NB bug?
"General failure" is a DOS message, followed by a slightly more
specific but not very helpful identification of what went wrong.
One often gets a general write failure when the FAT goes awry,
and you are then forced to use CHKDSK, locate the lost clusters,
and piece them together. It can happen with any word processor.
It may be a signal of coming disk problems, somewhat akin to
pain down the left arm after shovelling snow. You might consider
backing up all your files, and then reformatting your disk.
I would strongly recommend, however, that you invest in
that wonderful program Disk Technician Advanced. You might be
surprised at the number of repairs it will carry out. In any event,
I strongly doubt that your word processor (NB or WP) is at fault.
(3) --------------------------------------------------------------18----
Date: Thu, 9 Nov 89 00:56:19 EST
From: Itamar Even-Zohar <B10@TAUNIVM>
Subject: Re: 3.720 bug in Nota Bene (62)
One of the possibilities for gibberish in such situations as described
is BAD SECTORS not marked for DOS. You must check your disk
to verify the bad sectors are properly marked. Use, for instance,
Norton's DT /M, preferably version 4.5 etc.
Itamar Even-Zohar.
(4) --------------------------------------------------------------40----
Date: Fri, 10 Nov 89 15:39 CDT
From: LAVENDA@MSUS1.BITNET
Subject: Bug in Nota Bene or Disk Nearly Full?
In response to Malcolm Brown and James O'Donnell, I have checked with
Dragonfly, and they have not heard of this particular problem with large
files. In fact, "general failure" is a DOS message that NB passes along.
The critical question then, for both questionners is, "How much free space
is left on your disk?" Neither has indicated this in his message. If there
is not enough space for NB to make a spill file, DOS will not permit the
spill file to be written, and the error writing to disk or the general
failure message will be sent. Note, *this is not a bug in NB.* A similar
problem occurs when a RAM disk is used for the spill file. If there's not
enough space, NB cannot write the spill file. This file can get quite large.
I have often worked with a file some 475K in length, and have never encountered
this kind of problem. My advice is to check how much space is left on the disk.
Dragonfly offers the following advice for coping with this error message:
Save the file *under a different name.* This will at least preserve your
original file, and you may be able to save your most recent work using the
NB emergency exit.
O'Donnell mentions two other problems: little ASCII 001s and deteriorated
MODE commands. Dragonfly is aware of this problem, and has not yet isolated
it. It is intermittent and random.
A quick call to Dragonfly would have shed some light on these concerns and
solved the problem without having to suggest that there is a bug in NB.
Robert Lavenda
Dept of Sociology and Anthropology
St. Cloud State University
St. Cloud, MN 56301
LAVENDA@MSUS1
(5) --------------------------------------------------------------------
Date: 10 November 1989
From: Willard McCarty <MCCARTY@vm.epas.utoronto.ca>
Subject: NB ?bug ?feature
I regularly use NB to edit very large files, sometimes several of them
at once. The only time I have had a memory problem of the sort described
was when my "overflow" disk had insufficient space. I am dimly aware of
how complex the problem is to provide robust software memory-management,
and I am also aware of how few packages do it well. Nevertheless,
although strictly speaking NB may not have a "bug", it does seem to me
that its "feature" of not protecting you against the consequences needs
some rethinking.
I also wonder if this memory-management problem is related to the limits
one runs up against when attempting to define an especially large
segment of text. Siebert has told me that the next release will no
longer have these limits -- a welcome change. Will this change also fix
the currently lamented feature?
Certainly NB is a fine piece of work. If it weren't, we wouldn't be
trying such daring things with it as to edit 9 large files at the same
time. Some of us can remember when that was unthinkable; some of us
still cannot do it with what we've got. Still, a problem is a problem.
Willard McCarty