[Coco] No easy rename on OS-9 ?

John W. Linville linville at tuxdriver.com
Mon Mar 31 11:10:29 EDT 2014 

According to this man page, the link system call originated with
V7 Unix (circa 1979):

	http://comsci.liu.edu/~murali/unix/link.htm

The usage, of course, would be to create a link for the new directory
entry and the delete the original directory entry -- no need for
copying the actual data in the file.

Hth...

John

On Mon, Mar 31, 2014 at 11:01:56AM -0400, Mike Hughes wrote:
> 
> I'm afraid that you are missing the historical lineage of OS9.  OS9 was meant to be a "small computer" version of UNIX as was OS9's sister system, some unknown operating system called "Linux".  In UNIX, MV was born as a copy source to destination, then delete source so that is exactly the way it is done in OS9!  (and Linux).  Contact the creators of UNIX to find out why they did their programming in the way that they did.
> 
> 
> -----Original Message-----
> From: Gene Heskett <gheskett at wdtv.com>
> To: coco <coco at maltedmedia.com>
> Sent: Sun, Mar 30, 2014 11:13 pm
> 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
> 
>  
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

More information about the Coco mailing list