Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: Re: Can REL files be copied?
Message-ID: <2023@csd4.milw.wisc.edu>
Date: 14 Apr 89 00:57:23 GMT
References: <2030.2442CAD5@isishq.FIDONET.ORG>
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: Not around here. Totally Unorganized.  A Real Mess.
Lines: 55

In comp.sys.cbm article <2030.2442CAD5@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote:
]
] > From: dwtamkin@chinet.chi.il.us (David W. Tamkin)
] > Message-ID: <8190@chinet.chi.il.us>
] 
] > One difficulty in copying relative files is that EOI (st=64) is sent at the
] > end of every record.  The only way to know when to stop reading is an error
] > 50 (record not present) from the source disk.  The other is that BASIC's
] > INPUT#, GET#, and PRINT# commands respectively untalk, untalk, and unlisten
] > the addressed device when they are done, and unlistening or untalking a
] > disk
] > drive with an open relative file bumps the record pointer to the start of
] > the next higher record.
] 
]   Sorry to say this, but that serves you right for doing this in BASIC. File
]copying accross devices is slow enough without introducing the fun of a BASIC 
]interpreter. And, as you say, the BASIC commands do things you don't want them 
]to. That's always the risk when using a high-level language.
] 
....
]   Sounds like a good technique to me. Using a record buffer (only need one 
]page, since records won't exceed 255 bytes in length), an ML program could 
]copy the files quickly & easily:
...
]   In this way, commas, quotes, CRs, etc. all get copied into the new REL file 
]record. No intermediate untalks to foul up record pointers.

Also note that one of the better ways of finding the max record length
is to open the physical directory file and LOOK.  That has the
disadvantage of not working with RAMDOS and some less than compatible
disk drives.

Maintaining the end of record pointer is IMPORTANT....  UNI-COPY (aka
COPY-ALL) does not do this, at least in my experience.

Ironically, I believe UNI-COPY uses the method of finding the max
record length that I described.

] > But yes, relative files can be copied.  The c: DOS command in dual drives
] > (both from Commodore and from MSD) did it flawlessly.
] 
]   I have dumps of those ROMs in my Toronto office; perhaps it would be worth 
]seeing how they did it (it may not always be the best way, but it works well 
](therefore always a good candidate for "best" anyways).

Commodore probably just uses a buffer-duplicate routine.  Since the
REL file is very similar to a SEQ file, all that really has to be done
differently is the rebuilding of the Side Sector Tables (and Super SS
tables, on some drives).  Can't say for sure that this IS how it is
done, but I can't imagine many other ways.
--
jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
	West Allis, WI  53227-3329	"These aren't anybody's opinions."
Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)