[Coco] 'arc' copy command and Stack Overflow (ERROR #207)

[L. Curtis Boyle]

ATD would be Allen Dekok, one of the original 4 programmers for NitrOS-9. So that source (unless somebody merged comments from various releases) would be older than the one you worked on, I believe.

L. Curtis Boyle
curtisboyle at sasktel.net



> On Jan 25, 2015, at 11:36 PM, Gene Heskett <gheskett at wdtv.com> wrote:
> 
> On Sunday 25 January 2015 22:57:06 Stephen H. Fischer did opine
> And Gene did reply:
>> Be careful, NitrOS-9 has changed some related things.
>> 
>> My similar Archive program counted on the return code from Disk Full to
>> stop and tell the user.
>> 
>> Upon changing the syntax for another utility I thought I was done.
>> 
>> Then I discovered that the disk full error was not being returned to
>> the program.
> 
> That is a pretty serious charge Stephen.  No coder in his right mind would 
> remove that error return.
> 
> What edition number is your in use rbf.mn saying it is?
> 
>> Thus I needed to put a warning on my Colorful Sled text editor that use
>> with floppies or other small disks with little remaining space was not
>> advised.
>> 
>> No where to report the problem, no one interested, no one to fix it.
>> 
> Now days, this is the right place I think.  This is after all, a community 
> maintained os, and we are the community.
> 
> Humm, the rbf.mn in the level1 tree of my last pull back in Nov 2014is 
> edition 26!
> But let me check if level2 is different, I don't think they should be.
> At any rate, this is too short by several pages of printout, and does NOT 
> ever load an #e$Full error anyplace in it.
> 
> Humm, this is better, the level2 version claims its edition 37, much more 
> believable.
> 
> But while the labels etc are the same as when I last worked on it, someone 
> (ATD) now has comments all over, reverting some of my faster 6309 code for 
> the slower original.  The diff is 8 machine cycles per instance.  Now, 
> since there is no mention of anyone whose initials are ATD in the edit 
> trail at the top of the file, who is ATD?
> 
> At any rate, the path to an exit from the time regs.b is loaded with 
> #E$Full is quite convoluted.  Its getting loaded is the result of looking 
> at the allocation map and finding no more usable storage space.  My quick 
> checks do not see regs.b being used in the first 1 or two jumps after it 
> has been loaded, but it is possible someone re-used regs.b, clearing the 
> error.
> 
> If you would like to help test, back up a few releases and find an edition 
> 34,  move it into the current hg pull after renaming this one, and go back 
> the the build root, do a make clean dskclean; make dsk.  Build a system 
> disk using that one and then fill up a disk to overflowing.  If you do not 
> get an #E$Full (hex $F0, decimal 240) return then its being thrown away 
> someplace external to rbf.mn.
> 
>> Back in the Delphi days a report would have produced a fix to OS-9 in
>> days, maybe even from Kevin Darling.
>> 
> Be very very careful what you ask for.  One of Kevin's Christmas presents 
> was a new rbf.mn, but he had carefully excised all the multiple sector 
> cluster code from it. Maybe it was not intentional, but he crippled os9's 
> ability to use bigger hard drives forever when he did that. When I 
> volunteered to 6309 that code for Wes Gale all those years ago, a couple 
> of odd items made me go back and dis the rmf.mn on the level 2 
> distribution disk, where I did find that code and hauled it back into the 
> version I was working on, fixing one bug and making another that has since 
> been excised.
> 
> The point is, that without that code, we would all be scrounging dumpsters 
> looking for drives of a maximum size of a few k over 131 megabytes.  Now 
> we have a limit of 4Gb I believe with that code I put back in.  There was 
> one single equ hard coded in it, because there was not an equ listed in 
> what was rbfdefs at the time that matched it. Probably still isn't.
> 
> Do those tests please, and advise.  And who is ATD??
> 
>> SHF
>> 
>> Attached is a PDF of the commands, binary is on SHF888 on my web page:
>> 
>> http://home.mindspring.com/~sfischer1/
>> 
>> ----- Original Message -----
>> From: "Allen Huffman" <alsplace at pobox.com>
>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>> Sent: Sunday, January 25, 2015 5:26 PM
>> Subject: Re: [Coco] 'arc' copy command and Stack Overflow (ERROR #207)
>> 
>>>> On Jan 25, 2015, at 7:11 PM, Robert Gault <robert.gault at att.net>
>>>> wrote:
>>>> 
>>>> My arc has crc $B12074 and says ed2. There are other archive
>>>> programs such as lha that might have a larger capacity.
>>> 
>>> Ah. This "arc" is not an archiver -- it's a file copier, and one of
>>> the most-used tools I have ever used on OS-9. I will type out the
>>> help screen:
>>> 
>>> arc -?
>>> 
>>> Usage: arc [-acdeflmuv] from_dir to_dir
>>> 
>>>    a = all files
>>>    c = confirm file if not there
>>>    d = confirm non-existant directory
>>>    e = confirm existing directory
>>>    f = prevent copy of files
>>> 
>>>   ln = only n levels of the tree (1..9)
>>> 
>>>    m = do multilple (all) directories <- typo not mine
>>>    v = verify the copy
>>>    u = force uppercase for comparisons
>>> 
>>> I think Bill Pearce (?) was the one who said he also used it. I do
>>> not recall where I got it from, but it's amazing. I have never had
>>> it fail until tonight ;-) --
>>> Allen Huffman - PO Box 22031 - Clive IA 50325 - 515-999-0227
>>> (vmail/TXT only) Sub-Etha Software - http://www.subethasoftware.com
>>> - Established 1990! Sent from my MacBook.
>>> 
>>> P.S. Since 4/15/14, I have earned OVER $600  in Amazon gift cards via
>>> Swagbucks! Use my link and I get credit:
>>> http://swagbucks.com/refer/allenhuffman
> 
> 
> Cheers, Gene Heskett
> -- 
> "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>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>