[Coco] Dumb way to write 3.5" floppy in Coco RSBASIC?

[Gene Heskett]

On Saturday 13 December 2003 15:08, KnudsenMJ at aol.com wrote:
>In a message dated 12/13/03 2:38:23 AM Eastern Standard Time,
>
>gene.heskett at verizon.net writes:
>> Same difference Mike.  "zmodem" refers to the protocol, and its sz
>> or rz that executes the protocol.  As the archive is shipped with
>> the title of rzsz-version.number, the rzsz name has become
>> attached. BTW, since version 3.17, the one you are running came
>> from my machines compiler.  3.36 I believe is the last one I
>> built.
>
>Thanks for the history fill-in, Gene.  I don't have any version of
> zmodem, since this came out after I had stopped downloading from
> CIS/Delphi and was doing it at work on a Sun that could write PC
> format disks.  That would be after I got my MM/1 and could use it
> to convert PC disk files to Coco OS-9 format. The Sun used genuine
> adult Internet FTP.
>
>>  Dcheck of course will have a box of kittens over that as it
>> didn't check the link count in the fd IIRC!  One could call that a
>> bug in dcheck I suppose, but since we never had an "ln -s src
>> target" command in os9, well, ahh, mmm...  If I get my system back
>> up and running again, thats one of the utils I intend to write. 
>> That, and an 'mv' that picks up a dir entry and puts it in some
>> other dir, optionally renaming it as it goes.
>
>Right, I remember years ago the controversy over whether we should
> use symbolic links in OS-9, since DCheck would not approve.  Also,
> if you moved the real file, you had to re-link it (just like *NIX).

Thats not a problem if its done right.  Yes, DCheck will complain, but 
you'll notice it names the same file in two or more different 
dirpaths for the doubled (or more) allocation report.

As far as moving the file, which any editor will probably do if its 
edited, thats a non-problem since the move will also update the fd 
sector to the new locations LSN * length, and the dir entries all 
point to the same fd sector, its self correcting for all visible 
"copies".  They aren't really copies of course, its all the exact 
same file.

When one picks up a $20 byte directory entry and copies it to another 
directory, if at the same time the FD.LNK count is incremented in the 
files fd sector, then you are properly setup.  If you then 'del' that 
file in such and such a directory, the link count in that byte of the 
fd is decremented, and ONLY if its decremented to zero will the file 
itself be de-allocated.  Otherwise just that dir entry gets its first 
byte cleared as usual, causeing it to disappear from that directory 
listing only.

>There is a real nice 3rd-party "mv" command on my MM/1's OSK.  I
> *think* I might even have one on my Coco3.  I'll look.  Both
> require caution, since unlike OS-9, they don't check for
> overwriting an existing file.  --Mike K.

The ramifications of checking that I have to work out.  My current 
vision of a 'mv' command would simply pickup the complete dir entry 
from dir A and append it to dir B and clear that entry in dir A.

You are correct in that this could be disingenious if there was 
already a file in dir B by that name.  You could see that there were 
two there in a dir listing, but the system would always accept the 
first one it found for anything else.

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.