[Coco] No easy rename on OS-9 ?

Kip Koon computerdoc at sc.rr.com
Sun Mar 30 23:36:59 EDT 2014 

Hi Gene!
I'd like get a copy of those utilities you mentioned below.
Kip

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Gene Heskett
Sent: Sunday, March 30, 2014 11:13 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] No easy rename on OS-9 ?

On Sunday 30 March 2014 22:35:35 Kip Koon did opine:

> Hi Gene!
> I imagine that the MV command is coded that way to take into 
> consideration that the user would use different source and destination 
> drives. Kip
> 
That might be true Kip, like it was when floppies were "the" mass storage.

The linux version has sense enough to turn itself into a copy, then delete
when going across mount points.  No reason the os9 version couldn't have
done that too. But to too many, that thought of taking the long shot is
wrecked by considerations about the integrity of the media.

Me, having brought home venison from some long long shots, the fact that I
might miss never enters my mind.  If I miss, I am looking at the target by
the time the bullet gets there to see by how much, and the next shot _will_
hit. In fact the next 2 hit within 2.5" of each other from the edge of a
winter wheat field 640 yards away. When I stood up, it wasn't a brag when I
said I was going to go dress him as he would be laying there when I got
there, and he was.  At that point that good buck was still standing.

Unforch, it seems to be a bit of, when on the same mount point, a stretch to
have the os9 folks think in similar terms.

I cut new, almost sacred, ground when I wrote vfy all those years ago, by
not fiddling with a copy, but doing what it needed to do "in situ".  I think
it has worked out rather well.  Where else can you find, yet today, a
utility that can search through your os9boot file, locate a module by name
and fix or adjust that module?  Only dEd attempts that, but it verify's and
fixes the whole os9boot file only, no selectivity.

Where else can you find a utility that can recover every individual module
in an os9boot file, or even in the boottrack itself including the 6 byte
rsdos header on the track, and the arbitrary length trailer bytes from a
boottrack, as long as it does have a directory entry so it can be treated
like any other file.  I even have a utility that can do that (make a
directory entry for the boottrack) too but it is not part of vfy.

> -----Original Message-----
> From: coco-bounces at maltedmedia.com 
> [mailto:coco-bounces at maltedmedia.com]
> On Behalf Of Gene Heskett
> Sent: Friday, March 28, 2014 7:27 PM
> To: coco at maltedmedia.com
> Subject: Re: [Coco] No easy rename on OS-9 ?
> 
> On Friday 28 March 2014 19:20:57 Luis Antoniosi (CoCoDemus) did opine:
> > it turns out that there is a mv on rtsi:
> > 
> > ftp://www.rtsi.com/OS9/OS9_6X09/UTILITIES/mv.ar
> 
> Yup, looked at it. It does the move by copying it to the target 
> location, then deleting it from the source location. Needlessly 
> complex, subject to disk errors etc, when all you really need to do is 
> pick up the $20 bytes of the source directory entry and put it in the 
> target directory.  The directory entry is moved, but not even the FD 
> sector is moved.  Then go back and null the first byte of the source 
> dir, and to be complete, run dsort on both directories.
> 
> > There is also a cp and a ls.
> > 
> > On Wed, Mar 26, 2014 at 5:09 PM, Gene Heskett <gheskett at wdtv.com>
wrote:
> > > On Wednesday 26 March 2014 16:30:52 Luis Antoniosi (CoCoDemus) did
> 
> opine:
> > >> I'm very disappointed to discover that there ain't no I$Rename on 
> > >> OS-9. This is the reason the file becomes empty on cp/m wordstar 
> > >> save. As it tries to rename the scratch file and doesn't find it, 
> > >> it makes a new one. I was ignoring the BDOS rename call.
> > >> 
> > >> The rename.asm from os-9 repo is pretty large. I can make a 
> > >> smaller copy/delete but this is not the optimal solution and 
> > >> could run out of space.
> > >> 
> > >> As far I understood the rename.asm, it opens a directory raw file 
> > >> and change the name on it ? Is that correct ? Is it safe with 
> > >> multi threading doing this way ? What could be the other solution 
> > >> ? Using fork to create a rename process ?
> > > 
> > > I think so. One could fork the rename module.  But I just looked 
> > > at rename.asm and while it may work, what its doing makes 
> > > relatively little sense to me.
> > > 
> > > In fact, if I find the time, I might re-write a new rename/mv 
> > > utility.
> > > 
> > > Basic outline:
> > > 1. allocate 3 $20 byte buffers, and 4 256 byte buffers. that won't 
> > > be all, but the rest will be appended when the need arises.
> > > 2 strncpy old name to 256 byte buffer 1
> > > 3 strncpy new name to 256 byte buffer 2
> > > 4 save pwd
> > > 5 parse the 1st buffer to extract the ending filename
> > > 6 strncpy it to the first $20 byte buffer and the 3rd one too
> > > 7 parse the 2nd buffer to extract the ending filename
> > > 8 strncpy that to the 2nd $20 byte buffer.
> > > 9 parse the 1st 256 byte buffer to get the path to the directory
> > > 10 put that in 256 byte buffer 3
> > > 11 parse the 2nd 256 byte buffer for the path to that directory
> > > 12 save it in 256 byte buffer 4
> > > 13 set attrs for a directory and open the pathlist for 256 byte 
> > > buffer
> > > 3 14 setup a read loop, using the 3rd buffer as cache to look for 
> > > the name in buffer 1, or terminate with an E$FNF if not found.
> > > 15 when the match is found, strncpy 29 bytes from buffer 2 to 
> > > buffer 3. You do not want to destroy the FD's address.
> > > 
> > > Now, if NOT doing a move, seek back $20 bytes on that path and 
> > > write the $20 bytes of buffer 3.  Clean up and go home.  If doing 
> > > the move, null the first byte of buffer 1 and write its $20 bytes 
> > > back
> 
> instead.
> 
> > > Now for the move. open the pathlist in the 2nd 256 byte buffer as 
> > > a directory and seek to EOF.  Write the $20 bytes of buffer 3.  
> > > Close both directory files.  Then, just for S&G's fork a dsort 
> > > against both pathlists, one at a time.
> > > 
> > > Clean up and go home.
> > > 
> > > Cheers, Gene
> > > --
> > > 
> > > "There are four boxes to be used in defense of liberty:
> > >  soap, ballot, jury, and ammo. Please use in that order."
> > > 
> > > -Ed Howdershelt (Author)
> > > Genes Web page <http://geneslinuxbox.net:6309/gene>
> > > 
> > > 
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > http://five.pairlist.net/mailman/listinfo/coco
> 
> Cheers, Gene
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

More information about the Coco mailing list