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

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

spec for file entry for ProDOS extended (forked) files?

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

Contents

  spec for file entry for ProDOS extended (forked) files? ivan@ivanx.com - 2014-08-16 18:07 -0700
    Re: spec for file entry for ProDOS extended (forked) files? dempson@actrix.gen.nz (David Empson) - 2014-08-17 13:25 +1200
      Re: spec for file entry for ProDOS extended (forked) files? ivan@ivanx.com - 2014-08-16 19:38 -0700
    Re: spec for file entry for ProDOS extended (forked) files? D Finnigan <dog_cow@macgui.com> - 2014-08-18 17:08 +0000
      Re: spec for file entry for ProDOS extended (forked) files? ivan@ivanx.com - 2014-08-22 16:29 -0700
        Re: spec for file entry for ProDOS extended (forked) files? olivier.zardini@itn-group.eu - 2014-08-25 05:31 -0700

#1270 — spec for file entry for ProDOS extended (forked) files?

I have hunted high and low for any documentation as to where extended (forked) files are specified for the ProDOS file system, and all I have turned up are what I already knew: the non-forked specs in the ProDOS 8 Technical Reference manual (or Beneath Apple ProDOS), plus ProDOS Tech Note 25, which covers extended files.

The thing is that Tech Note #25 only describes the Extended Key Block; it makes no mention of what the File Entry (or, as Beneath Apple ProDOS calls it, the File Descriptive Entry) is supposed to look like for an extended file (beyond that the storage type nibble should be $5).

Most of a File Entry for an extended file seems pretty straightforward, but in particular I'm curious about the file length at offset $15-17. It always seems to be 512 for an extended file ($000200), perhaps because that's the length of the Extended Key Block (which itself contains file lengths for both the data fork and the resource fork).

But is this actually specified or documented anywhere? Does anyone know of any exceptions, where the file length field for an extended file contains something other than 512? It seems odd not to have it contain the total number of bytes in both the data and resource forks, since at least that would allow ProDOS 8 to know how much data is in the file, despite not being able to do much with it.

For what it's worth, the blocks used field in the File Entry of an extended file appears to be accurate: it contains the total of all data blocks and any corresponding index and master index blocks for both the data and resource forks, plus the extended key block. So again, it seems suprising that total data wouldn't be properly represented in the File Entry.

Thanks,
Ivan.

[toc] | [next] | [standalone]

#1271

<ivan@ivanx.com> wrote:

> I have hunted high and low for any documentation as to where extended
> (forked) files are specified for the ProDOS file system, and all I have
> turned up are what I already knew: the non-forked specs in the ProDOS 8
> Technical Reference manual (or Beneath Apple ProDOS), plus ProDOS Tech
> Note 25, which covers extended files.

I've only ever been aware of PDOS TN#25 as the official reference for
the disk structure of extended files.

> The thing is that Tech Note #25 only describes the Extended Key Block; it
> makes no mention of what the File Entry (or, as Beneath Apple ProDOS calls
> it, the File Descriptive Entry) is supposed to look like for an extended
> file (beyond that the storage type nibble should be $5).
> 
> Most of a File Entry for an extended file seems pretty straightforward,
> but in particular I'm curious about the file length at offset $15-17. It
> always seems to be 512 for an extended file ($000200), perhaps because
> that's the length of the Extended Key Block (which itself contains file
> lengths for both the data fork and the resource fork).
>
> But is this actually specified or documented anywhere? Does anyone know of
> any exceptions, where the file length field for an extended file contains
> something other than 512? It seems odd not to have it contain the total
> number of bytes in both the data and resource forks, since at least that
> would allow ProDOS 8 to know how much data is in the file, despite not
> being able to do much with it.

I'm not aware of any specific documentation on this and don't recall
ever having a close look myself.

It is probably an arbitrary choice so that ProDOS-8 at least displays
something, even if it isn't accurate. Maintaining an accurate byte count
in the directory would add more overhead (though not much, if GS/OS has
to write it anyway to update the block count and other details like the
modified timestamp).

GS/OS won't care what that field contains, since it would recognise the
storage type and fetch the actual lengths from the mini-entries in the
extended key block.

Probably the best reason for this arrangement is that it is possible for
the total file size in bytes to be unrepresentable in the directory
entry, since the total size of the data and resource forks could exceed
16 MiB, but the directory entry only has a 3-byte field.

> For what it's worth, the blocks used field in the File Entry of an
> extended file appears to be accurate: it contains the total of all data
> blocks and any corresponding index and master index blocks for both the
> data and resource forks, plus the extended key block. So again, it seems
> suprising that total data wouldn't be properly represented in the File
> Entry.

I expect having an accurate block count is more important, e.g. for
simple disk space usage checks.
-- 
David Empson
dempson@actrix.gen.nz

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

#1272

On Saturday, August 16, 2014 9:25:57 PM UTC-4, David Empson wrote:

> I've only ever been aware of PDOS TN#25 as the official reference for
> the disk structure of extended files.
> 
> > Ivan X wrote:
> 
> > Most of a File Entry for an extended file seems pretty straightforward,
> > but in particular I'm curious about the file length at offset $15-17. It
> > always seems to be 512 for an extended file ($000200), perhaps because
> > that's the length of the Extended Key Block (which itself contains file
> > lengths for both the data fork and the resource fork).
> 
> > It seems odd not to have it contain the total
> > number of bytes in both the data and resource forks, since at least that
> > would allow ProDOS 8 to know how much data is in the file, despite not
> > being able to do much with it.
> 
> Probably the best reason for this arrangement is that it is possible for
> the total file size in bytes to be unrepresentable in the directory
> entry, since the total size of the data and resource forks could exceed
> 16 MiB, but the directory entry only has a 3-byte field.

Compelling theory. Probably would not have been the only way to solve the problem (for those cases where a file really is >16M, for example, it could probably just store 16M-1 as the length and no one would much complain), but I hadn't thought about that possibility; thanks. Or, since ProDOS 8 can't deal with extended files anyway, maybe an obviously inaccurate file length is a way of signaling that they're inaccessible anywhere, not only in newer programs that know about extended files.

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

#1273

Look at the GS/OS source. That, and the Tech Note, were my sources for
writing the implementation that I use in Format Converter for Mac GUI Vault.

In fact, this is a large block that I have copied into the source code as a
comment:

			Storage type $5 is used by the ProDOS FST in GS/OS to store extended
			files.
			The key block of the file points to an extended key block entry.  The
			extended
			key block entry contains mini-directory entries for both the data fork
			and
			resource fork of the file.  The mini-entry for the data fork is at offset
			+000
			of the extended key block, and the mini-entry for the resource fork is at
			offset +$100 (+256 decimal).

			The format for mini-entries is as follows:

			storage_type    (+000)    Byte    The standard ProDOS storage 
         			                         type for this fork of the file.  
        			                          Note that for regular directory 
         			                         entries, the storage type is the 
        			                          high nibble of a byte that contains 
        			                          the length of the filename as the 
         			                         low nibble.  In mini-entries, the 
        			                          high nibble is reserved and must be 
        			                          zero, and the storage type is 
        			                          contained in the low nibble.
			key_block       (+001)    Word    The block number of the key 
     			   	                          block of this fork.  This value and 
       			  	                          the value of storage_type combine to 
      				                          determine how to find the data in 
       				                          the file, as documented in the 
       			                           ProDOS 8 Technical Reference Manual.
			blocks_used     (+003)    Word    The number of blocks used by 
 			                                 this fork of the file.
			EOF             (+005)    3 Bytes Three-byte value (least 
      			                            	significant byte stored first) 
         			                        representing the end-of-file value 
          			                        for this fork of the file.

			All remaining bytes in the extended key block are reserved and must be
			zero.

-- 
]DF$
Apple II Book: http://macgui.com/newa2guide/
Usenet: http://macgui.com/usenet/  <-- get posts by email!
Apple II Web & Blog hosting: http://a2hq.com/

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

#1274

On Monday, August 18, 2014 1:08:09 PM UTC-4, D Finnigan wrote:
> Look at the GS/OS source.

Good idea. Thanks for hosting! I had a look at PRODOS.FST and it confirmed what I'd already observed -- that an extended file shows a length of 512 in its File Entry.The EOF calls are rerouted through the appropriate fork of the mini-entry, so the initial 512-byte EOF in the File Entry, for the Extended Key Block, never gets changed. So it doesn't really illuminate as to the why, but it does confirm the observed behavior.

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

#1277

  You can also have a look into CADIUS source code (id you speak C language) where all the Prodos file system is handled (read / write) and the data structures exposed :

http://www.brutaldeluxe.fr/products/crossdevtools/cadius/index.html

    Olivier

[toc] | [prev] | [standalone]

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

csiph-web