Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3518 > unrolled thread

Best way to specify a file a not movable within the volume

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Best way to specify a file a not movable within the volume Benoit0123 <bgilon@free.fr> - 2017-06-09 12:40 +0000
    Best way to specify a file a not movable within the volume Antoine Vignau <antoine.vignau@laposte.net> - 2017-06-09 08:27 -0700
      Re: Best way to specify a file a not movable within the volume John Brooks <jbrooks@blueshiftinc.com> - 2017-06-09 21:17 -0700
        Re: Best way to specify a file a not movable within the volume Steven Hirsch <snhirsch@gmail.com> - 2017-06-10 09:27 -0400
          Re: Best way to specify a file a not movable within the volume James Davis <JPD.Enterprises@outlook.com> - 2017-06-10 08:55 -0700
            Re: Best way to specify a file a not movable within the volume Steven Hirsch <snhirsch@gmail.com> - 2017-06-11 10:24 -0400

#3518 — Best way to specify a file a not movable within the volume

Hello to everyone out there,
I know that the ProDOS basically does not attempt to move file's data within
a volume for the purpose of setting up enough space for a new file entry.
But I also know that some utilities out there offer to move data around a
ProDOS volume solely to speed up frequent usage file access by minimizing
drive head moves while doing so. So my query is very simple, what would be
the best and simplest way to specify that a file must not be moved around.
Is this the role for one of the "reserved" attributes bits (along the
backup, write enable and read enables ones)?

Or should I depend to one of the ProDOS file type values. I am aware that
the BAD block filetype already exists, but I am reluctant to select this
file type as it serves another purpose for data safety. Might the filetype
designating a "Pascal area" fill this gap vis a vis of such disk
defragmenter (I hate this term...) utilities?
The purpose would be to reserve a ProDOS file entry for DOS 3.3 VTOC storage
in 5'1/4 floppies with dual OS capabilities.


Thank your for any return on that point,
Best regards,
Benoît


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [next] | [standalone]

#3522

I knew why you were asking ;-)

You may reserve blocks mapping track $11 in ProDOS' bitmap block.
I like the BAD filetype usage but you are right, that is not really bad blocks. There are no options today on ProDOS 8.

John Brooks may have ideas...

Antoine

[toc] | [prev] | [next] | [standalone]

#3531

On Friday, June 9, 2017 at 8:27:03 AM UTC-7, Antoine Vignau wrote:
> I knew why you were asking ;-)
> 
> You may reserve blocks mapping track $11 in ProDOS' bitmap block.
> I like the BAD filetype usage but you are right, that is not really bad blocks. There are no options today on ProDOS 8.
> 
> John Brooks may have ideas...
> 
> Antoine

> So my query is very simple, what would be 
> the best and simplest way to specify that a file must not be moved around. 
> Is this the role for one of the "reserved" attributes bits (along the 
> backup, write enable and read enables ones)? 

I agree with Antoine that the simplest approach is to just reserve the track $11 blocks in the volume bitmap without having them assigned to any ProDOS file. This is how ProDOS 'reserves' the boot blocks, root directory blocks, and bitmap blocks.

One possible drawback is that if the 5.25 ever has disk errors, a disk recovery tool will likely free those track $11 blocks as part of the repair effort.

A second option is to create a dummy file of storage type 4 (pascal). IMO this is a better approach than using a bad block file because no index block will be allocated since pascal files must be contiguous.

Other options are to make a bad block file (with one extra block assigned to the index block), or use the GS/OS 'fork' file with storage type 5, which will also require an extra block to manage the resource & data forks.

http://www.1000bit.it/support/manuali/apple/technotes/pdos/tn.pdos.25.html

Hope that helps.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#3534

On 06/10/2017 12:17 AM, John Brooks wrote:

> On Friday, June 9, 2017 at 8:27:03 AM UTC-7, Antoine Vignau wrote:
>> I knew why you were asking ;-)
>> 
>> You may reserve blocks mapping track $11 in ProDOS' bitmap block. I like
>> the BAD filetype usage but you are right, that is not really bad blocks.
>> There are no options today on ProDOS 8.

> I agree with Antoine that the simplest approach is to just reserve the
> track $11 blocks in the volume bitmap without having them assigned to any
> ProDOS file. This is how ProDOS 'reserves' the boot blocks, root directory
> blocks, and bitmap blocks.

> One possible drawback is that if the 5.25 ever has disk errors, a disk
> recovery tool will likely free those track $11 blocks as part of the repair
> effort.
Here's a discussion on the subject from my ProPartition package (creates 
virtual CP/M volume at the end of a ProDOS volume).  My original approach (aka 
"Hidden Method") was a bit different from anything discussed here:

--------

Appendix A

The original ('Hidden') method of installing CP/M on a hard drive involved
setting the ProDOS volume size (in the volume directory) to an artificially
low number; shortening the volume (so far as ProDOS was concerned) by the
length of the CP/M partition.  The bitmap was also adjusted to reflect the
"new" size, although this adjustment only occurred in what ProDOS would regard
as the "last" block of the "new" SHORTER bitmap.  The emphasis here is
deliberate.  Some potential problems were created by this method:

Problems with the Hidden Method:

- Certain hard drives insist upon reporting their volume sizes (on a ProDOS
STATUS call) based upon either internal partition information unrelated to
information in the volume directory (OKS MultiKache and Apple SCSI <I
think..>) or, worse yet, hardcoded data in the controller EPROM (older Sider
10 & 20).  This could potentially be disastrous if a disk utility became
confused.  It _is_ a loosely defined portion of the ProDOS device spec, so it
is hard to tell who is wrong.

- Volume repair programs such as MR.FIXIT will think that any blocks between
the "new" bitmap end and the "old" bitmap end are erroneously marked as "in-
use".  If you tell it to fix the directory, these will be freed for file
storage.  If you write real information into the new blocks, then attempt to
remove the CP/M partition, serious corruption of the volume bitmap will occur.

- Along the same lines, a soft format of the partitioned volume would cause
one of two problems:

      - If STATUS reports the modified drive size, the bitmap size  will be
      incorrect upon re-format.  This is just the same as  running MR.FIXIT..

      - If STATUS reports the true volume size, then you will  totally lose the
      CP/M partition.  The original PART program  had no ability to recover
      from this type of damage.

- Optimizer utilities (BEACH.COMBER and/or ProSel-16 Optimizer) will similarly
destroy the integrity of the upper bitmap.

- Archive programs such as Glen Bredon's BACKUP/RESTORE from ProSel-8 will not
"see" the CP/M partition, and thus will not be able to back it up.  I think
that the Sider tape backup program works the same way, as Glen wrote it.

So what have I done about all this? Read on:

I had been unhappy with this compromise, thus the new PART program.  It will
support the older "HIDDEN" CP/M partition and a new "VISIBLE" method as well.
It additionally allows a prior installation to be converted to the new
algorithm (and back again!).

The VISIBLE method leaves the volume size untouched, and merely marks the
areas of the bitmap corresponding the CP/M as in-use.  MR.FIXIT will report a
large number of "unused" blocks marked as "in-use" and query you for
permission to free them.  Do _not_ do this.  However, if you should happen to,
all is not lost.

Recovering from a "free unused blocks" utility:

Assuming that you have not written huge amounts of data to the disk, merely
boot CP/M (yes, the driver will still be able to find the partition), then run
PRO/PART.  First, convert the installation to HIDDEN, then immediately convert
it back to VISIBLE and bingo! the bitmap is repaired.  This method may also be
used immediately after a soft format.  I define "soft" as one that merely
writes the ProDOS boot block, and re-initializes the directory and bitmap.
Naturally a "hard" or low-level physical format of the disk will destroy
everything on it..

The above technique will not currently do anything to restore a HIDDEN
installation that has been re-formatted or MR.FIX'ed.  I am working on a
method for doing this, but it will not be very simple and may involve some
snooping with INFO.DESK or BLOCK.WARDEN.  Not for beginners.  For that reason,
I am going to recommend the VISIBLE method for most users.

The new driver file automatically recognizes either partition method
transparently to the user.

Advantages of the Visible Method:

- ProSEL-8 BACKUP/RESTORE will now allow you to archive your CP/M partition
along with the ProDOS files.  You may NOT use RECOVER to selectively restore
the CP/M partition, as it does not represent a true ProDOS file.  A full
restore would be necessary in the case of an accident.

- You may use an optimize utility on your ProDOS files without fear of damage
to the CP/M partition.

[toc] | [prev] | [next] | [standalone]

#3535

On Saturday, June 10, 2017 at 6:27:56 AM UTC-7, Steven Hirsch wrote:
> On 06/10/2017 12:17 AM, John Brooks wrote:
> 
> > On Friday, June 9, 2017 at 8:27:03 AM UTC-7, Antoine Vignau wrote:
> >> I knew why you were asking ;-)
> >> 
> >> You may reserve blocks mapping track $11 in ProDOS' bitmap block. I like
> >> the BAD filetype usage but you are right, that is not really bad blocks.
> >> There are no options today on ProDOS 8.
> 
> > I agree with Antoine that the simplest approach is to just reserve the
> > track $11 blocks in the volume bitmap without having them assigned to any
> > ProDOS file. This is how ProDOS 'reserves' the boot blocks, root directory
> > blocks, and bitmap blocks.
> 
> > One possible drawback is that if the 5.25 ever has disk errors, a disk
> > recovery tool will likely free those track $11 blocks as part of the repair
> > effort.
> Here's a discussion on the subject from my ProPartition package (creates 
> virtual CP/M volume at the end of a ProDOS volume).  My original approach (aka 
> "Hidden Method") was a bit different from anything discussed here:
> 
> --------
> 
> Appendix A
> 
> The original ('Hidden') method of installing CP/M on a hard drive involved
> setting the ProDOS volume size (in the volume directory) to an artificially
> low number; shortening the volume (so far as ProDOS was concerned) by the
> length of the CP/M partition.  The bitmap was also adjusted to reflect the
> "new" size, although this adjustment only occurred in what ProDOS would regard
> as the "last" block of the "new" SHORTER bitmap.  The emphasis here is
> deliberate.  Some potential problems were created by this method:
> 
> Problems with the Hidden Method:
> 
> - Certain hard drives insist upon reporting their volume sizes (on a ProDOS
> STATUS call) based upon either internal partition information unrelated to
> information in the volume directory (OKS MultiKache and Apple SCSI <I
> think..>) or, worse yet, hardcoded data in the controller EPROM (older Sider
> 10 & 20).  This could potentially be disastrous if a disk utility became
> confused.  It _is_ a loosely defined portion of the ProDOS device spec, so it
> is hard to tell who is wrong.
> 
> - Volume repair programs such as MR.FIXIT will think that any blocks between
> the "new" bitmap end and the "old" bitmap end are erroneously marked as "in-
> use".  If you tell it to fix the directory, these will be freed for file
> storage.  If you write real information into the new blocks, then attempt to
> remove the CP/M partition, serious corruption of the volume bitmap will occur.
> 
> - Along the same lines, a soft format of the partitioned volume would cause
> one of two problems:
> 
>       - If STATUS reports the modified drive size, the bitmap size  will be
>       incorrect upon re-format.  This is just the same as  running MR.FIXIT..
> 
>       - If STATUS reports the true volume size, then you will  totally lose the
>       CP/M partition.  The original PART program  had no ability to recover
>       from this type of damage.
> 
> - Optimizer utilities (BEACH.COMBER and/or ProSel-16 Optimizer) will similarly
> destroy the integrity of the upper bitmap.
> 
> - Archive programs such as Glen Bredon's BACKUP/RESTORE from ProSel-8 will not
> "see" the CP/M partition, and thus will not be able to back it up.  I think
> that the Sider tape backup program works the same way, as Glen wrote it.
> 
> So what have I done about all this? Read on:
> 
> I had been unhappy with this compromise, thus the new PART program.  It will
> support the older "HIDDEN" CP/M partition and a new "VISIBLE" method as well.
> It additionally allows a prior installation to be converted to the new
> algorithm (and back again!).
> 
> The VISIBLE method leaves the volume size untouched, and merely marks the
> areas of the bitmap corresponding the CP/M as in-use.  MR.FIXIT will report a
> large number of "unused" blocks marked as "in-use" and query you for
> permission to free them.  Do _not_ do this.  However, if you should happen to,
> all is not lost.
> 
> Recovering from a "free unused blocks" utility:
> 
> Assuming that you have not written huge amounts of data to the disk, merely
> boot CP/M (yes, the driver will still be able to find the partition), then run
> PRO/PART.  First, convert the installation to HIDDEN, then immediately convert
> it back to VISIBLE and bingo! the bitmap is repaired.  This method may also be
> used immediately after a soft format.  I define "soft" as one that merely
> writes the ProDOS boot block, and re-initializes the directory and bitmap.
> Naturally a "hard" or low-level physical format of the disk will destroy
> everything on it..
> 
> The above technique will not currently do anything to restore a HIDDEN
> installation that has been re-formatted or MR.FIX'ed.  I am working on a
> method for doing this, but it will not be very simple and may involve some
> snooping with INFO.DESK or BLOCK.WARDEN.  Not for beginners.  For that reason,
> I am going to recommend the VISIBLE method for most users.
> 
> The new driver file automatically recognizes either partition method
> transparently to the user.
> 
> Advantages of the Visible Method:
> 
> - ProSEL-8 BACKUP/RESTORE will now allow you to archive your CP/M partition
> along with the ProDOS files.  You may NOT use RECOVER to selectively restore
> the CP/M partition, as it does not represent a true ProDOS file.  A full
> restore would be necessary in the case of an accident.
> 
> - You may use an optimize utility on your ProDOS files without fear of damage
> to the CP/M partition.

Could you create a real ProDOS binary file called, for example, CPM that is large enough to hold the CPM partition and that CPM would see as a real CPM partition?

[toc] | [prev] | [next] | [standalone]

#3536

On 06/10/2017 11:55 AM, James Davis wrote:

> Could you create a real ProDOS binary file called, for example, CPM that is
> large enough to hold the CPM partition and that CPM would see as a real CPM
> partition?

The partition must appear as a contiguous set of blocks to CP/M, so a generic 
ProDOS file isn't compatible with my scheme.  It's technically possible to 
remap CP/M BIOS disk calls into an actual ProDOS file (this approach was used 
by one of the later ALS CP/M boards), but I decided against that approach due 
to the amount of overhead it would introduce.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web