Path: utzoo!attcan!uunet!portal!cup.portal.com!David_W_Tamkin
From: David_W_Tamkin@cup.portal.com
Newsgroups: comp.sys.cbm
Subject: Re: {Feeling embarrassed} Sector Protection, continued
Message-ID: <10901@cup.portal.com>
Date: 5 Nov 88 04:35:16 GMT
References: <10763@cup.portal.com> <2710@mibte.UUCP>
Organization: The Portal System (TM)
Lines: 50

Jim Harvey in <2710@mibte.UUCP> offers me the suggestion:

> In article <10763@cup.portal.com>, David_W_Tamkin@cup.portal.com writes:

< At any rate, the relative file idea didn't work.  Does anyone know a way to
< protect sectors that are not in a file from being de-allocated by a validation
< on a 1571 or 1541, short of using a write-protect tab or changing the DOS
< version byte, so that other writes can still be done to the disk without
< having to reallocate the boot sectors after each collect?

[Jim's citation of my signature omitted]

> I think the answer is to not validate the disk.  A long time ago
> (in a galaxy far, far away...  no, No.... It was in Detroit.) I
> wrote a program that would UNvalidate a disk.  It would read the
> whole disk and allocate any sector that contained data.  This is
> a useful thing if you have done a validation in error or want to
> save a "Splat" file from destruction.  Actually, I wanted to be
> able to store other adventure games on my Zork disks, it worked
> fine for this.

Jim, the only time I would never validate a disk again is when I have stopped
writing to that disk for good.  At that point I can use a write-protect tab
and not care whether the maverick sector is allocated or not, since nothing
can be written over it anyway.

Your program for undoing a validation wouldn't help me.  For one thing, it
would allocate all sectors that had been in files I had intentionally 
scratched, wasting space I'd rather use for current data (or, if there is
still a lot of space on that disk, making DOS jump all over the place in
writing files); for another, if I have to go through a second process after
each validation, a quick

open1,9,15:open2,9,2,"#":pR1,"b-a 0 1 0":close2:close1
(I don't trust dclose to close the files in predictable order)

is probably less work than digging out a disk with your program on it and 
watching it allocate every sector that contained anything different from
original formatting filler.

Thank you for your suggestion, but it wouldn't work for me.  Thank you also
for reading both parts of the article before responding.

[For those of you wondering why I abbreviated print# to pR but not open to oP
nor close to clO, I am showing how I normally type those keywords.  The
annoyance of shifting is not worth typing only two fewer characters, so I
type out "open" and "close", but "print#" has four more characters than its
abbreviation and needs a shift for its octothorpe anyway.]

David_W_Tamkin@cup.portal.com  ||  sun!portal!cup.portal.com!david_w_tamkin