<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Sun, 10 Nov 1985 00:02:00 MST
From   : Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: NULU11 bugs (again)

The following is relayed from CompuServe's CP-MIG:

#: 152927 S1/General
    07-Nov-85  17:19:21
Sb: #NULU Bug
Fm: Charles Hart 72755,500
To: All

So you thought the reported bug in NULU v1.1 (or v1.2) was so obscure
it could never happen to you, boobie?  Check out the comprehensive
directory listing below and see if you can spot at first glance what
NULU did when I extracted a file just a _little_ but larger than the
buffer to another drive.

The first clue I had was that the directory program reported 189k
used of 191k and 5k free. (The listing below is only a partial due to
space restrictions.)  Something didn't add up.  So, I tried adding up
the individual file sizes - 189k was correct, 5k free was _not_.

I then did the following:

 B0>Z A:CP4KER.* [C

Us  Fn      Ft   Ex S1 S2 RC  Group #'s
============================================================================
00  cp4ker  dqc  00 00 00 80  4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B
00  cp4ker  dqc  01 00 00 80  5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 68 67
00  cp4ker  dqc  02 00 00 01  5C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  cp4ker  hqx  00 00 00 80  6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79
00  cp4ker  hqx  01 00 00 1A  7A 7B 7C 7D 00 00 00 00 00 00 00 00 00 00 00 00
============================================================================
 2 Files, occupying 53k of 191k total capacity
 23 directory entries and 5k bytes remain on a:

No question about it, the third extent (or whatever they call it) for
CP4KER.DQC is really messed up.  Never saw anything like that before,
and NULU will do it all day long.  Tried it on two 40k+ files and
ended up being told I had a 220k disk - when all you can pack on this
KPII is 191k max!

My extractions and unsqueezations were done from my HD first to a
floppy and then to the ramdisk.

SYSOP SirCharles has mentioned from time to time that there was a bug
in NULU - he's correct, and I suggest that all output from NULU be
inspected very closely before use.  Or use LU310 instead.  After all,
where there is one bug, there may be more....


#: 153048 S1/General
    09-Nov-85  15:01:36
Sb: #153010-NULU Bug
Fm: Mike Allen 74146,2717
To: Pete Holsberg 70240,334 (X)

I'm getting into the middle of this thread, but it sounds like you
guys are discussing the same problem I've seen with NULU11 on a Zenith
Z-89 using 3 floppies and 2 5-mb hard-drives with ZCPR3.  I find that
when I try to extract or unsqueeze a file other than to the drive/user
that the LBR file exists on AND the extracted file requires more than one
extent, I get a bad extracted file.  Who's got the fix?

#: 152973 S1/General
    08-Nov-85  07:50:45
Sb: #152956-#NULU Bug
Fm: Charles Hart 72755,500
To: <MoM> John Deakin 74015,1624 (X)

John, do the following to see the problem:

1) Make a LBR file with at least one file greater that your buffer
size as shown by NULU when you sign on - for most computers with 64k a
file of 55k will be enough.  It doesn't matter if the file is squeezed
or not, I just happened to be working with that type of file.

2) Put the LBR file on drive A:

3) Enter Nulu and extract the file to drive B:, any user area. You
will see the problem I outlined.

The problem is extraction to another drive, not another user area on
the same drive or the same user area on the same drive.  This is why
it took so long for me to know I was hit by the bug.  I have had
strange things happen to my large files before, but decided
(incorrectly, it seems) that operator error was involved.  It was,
just not the type I thought...

Further review indicates that the extent involved seems to be the
third one (numbered 02H) only, the sector reuse stops in the 4th one.


#: 152992 S1/General
    08-Nov-85  20:02:15
Sb: #152982-#NULU Bug
Fm: Charles Hart 72755,500
To: <MoM> John Deakin 74015,1624 (X)

John, the bug must be related to the allocation size - on your K10 the
smallest file size is 4k, right?  Try the test with a file of 4 x 68k
and see if it works.

All of my errors were on writes to a 191k, 1k alllocation floppy.
Yes, I have made all the patches to NULU - at least the v1.2 I'm using
said in the LBR file the FIX patch had been made. One more thing:  Be
sure to be logged on the drive you are extracting to with the -u
command.  It may be that the change in allocation size between the two
I was using is a factor - the HD has 8k allocations and the floppy has
1k.

Interesting, no?
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>