Date : Thu, 14 Nov 1985 19:04:00 MST
From : Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: NULU15 buggy - removed from SIMTEL20
Because serious bugs have been reported, NULU15 has been removed from
SIMTEL20 and my RCP/M. The messages below explain in detail by this
action is necessary. NULU11 suffers from the same problems. It is
recommended that all verions of NULU not be used.
NULU is one of those programs that's "free for the using" but no
source code has been provided. It's a real shame because the program
has a lot of nice features and could have been fixed by someone with
the time to do it. The author has apparently not been able to
duplicate the elusive bug, which apparntly can only be duplicated in
systems which have differing group size allocations on various drives.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
uucp: ...!seismo!SIMTEL20.ARPA!W8SDZ
uucp: ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz
uucp: ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz
--forwarded messages--
#: 153121 S1/General
10-Nov-85 16:47:35
Sb: NULU15 buggy
Fm: <MoM> John Deakin 74015,1624
To: All
Just grabbed NULU15 off Poppourri this morning, and tried it out on
the previously reported problem(s).
When creating a new LBR on a different DU, it now remains on the
default drive from which called, as it should. One bug dead.
However, the most serious is still there. When extracting a large
file (about 70K in this case) from a LBR on my hard disk with 4K
blocks, to my floppy with 2K blocks, it trashes the file, with no
warning. Only way to check it is run a CRC check on the results.
#: 153183 S1/General
11-Nov-85 08:18:48
Sb: #Nulu15 Buggy Too!
Fm: Charles Hart 72755,500
To: All
Well, the NULU bug has not been fixed. The following display of the
directory tracks was taken after using NULU15 to remove a 55k file
from KERMT405.LBR on drive C0: (a drive with 8k minimum allocation
size) to drive F0: (a drive with 1k minimum allocation size).
F0>Z [C
Us Fn Ft Ex S1 S2 RC Group #'s
=============================================================================
00 cp4sys aqm 00 00 00 80 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13
00 cp4sys aqm 01 00 00 80 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23
00 cp4sys aqm 02 00 00 80 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23
00 cp4sys aqm 03 00 00 38 24 25 26 27 28 29 2A 00 00 00 00 00 00 00 00 00
=============================================================================
2 Files, occupying 55k of 191k total capacity
60 directory entries and 152k bytes remain on b:
Clearly there is something wrong with the third directory entry used
- anybody got any idea what?
#: 153224 S1/General
12-Nov-85 13:17:13
Sb: #153183-#Nulu15 Buggy Too!
Fm: <MoM> John Deakin 74015,1624
To: Charles Hart 72755,500 (X)
Right. And if you take a look at the file, you'll find your Ex 01 &
02, are really both Ex 02 (the THIRD extent).
#: 153229 S1/General
12-Nov-85 19:20:15
Sb: #153224-Nulu15 Buggy Too!
Fm: Charles Hart 72755,500
To: <MoM> John Deakin 74015,1624 (X)
Did you call Murray? I called once, so I think someone else should
advise him that v1.5 continues the tradition...
#: 153234 S1/General
12-Nov-85 19:36:25
Sb: #153183-#Nulu15 Buggy Too!
Fm: Pete Holsberg 70240,334
To: Charles Hart 72755,500 (X)
Oh, no! Are you using LU-mode extraction or FILESWEEP-mode? Do you
have the proper syntax in LU-mode? (My success reports were on trials
performed in LU-mode.)
#: 153235 S1/General
12-Nov-85 19:39:50
Sb: #153234-#Nulu15 Buggy Too!
Fm: Charles Hart 72755,500
To: Pete Holsberg 70240,334 (X)
filesweep and lu-mode. Seems to make no difference. This is a
strange one, no?
#: 153246 S1/General
12-Nov-85 20:46:26
Sb: #153235-#Nulu15 Buggy Too!
Fm: Pete Holsberg 70240,334
To: Charles Hart 72755,500 (X)
See above messages. I got NULU to fail by doing an unnatural
extraction. (Unnatural only because of my 6 logical HD drives and a
ramdisk; my FD hardly gets any use at all except to upload files
people send me! I got yours today, thank you!!)