Re: Help! Filetype $00 problems . . .

[dempson@actrix.gen.nz (David Empson)]

David Miller <xjustdavex@glis.net> wrote:

> But they didn't add any extra code.  That code has been there since the
> beginning.  Basically, it refuses to perform any operations on any file
> with a storage type it doesn't recognize.  It was never told how to
> recognize storage type 5 (extended files) so therefore, it won't do
> anything with it.  How is ProDOS supposed to know that the filename is
> stored the same way?  They could have defined a storage type that
> defines the directory entry differently (not likely, but possible
> nonetheless).

I think that would be highly unlikely.  The storage type is supposed to
define what the key block and the rest of the file look like, not the
directory entry.  The version fields (in theory) or the entry length
might have been used to add extensions.

A more plausible explanation can be gleaned from looking at storage type
4, which is the "pascal area" reserved on a ProFile by the Apple Pascal
ProFile Manager.

This must be a contiguous range of blocks, and always goes at the end of
the disk.  Its directory entry in the ProDOS catalog is always called
PASCAL.AREA, and the file appears to be locked.

The user must not delete or rename this file, or it may prevent the
Pascal ProFile Manager from locating it.  It therefore makes sense for
ProDOS-8 to disallow any attempt to rename (or unlock) the file.

Going one step further, ProDOS probably has common code which validates
most file access calls which specify a pathname.  This will be checking
for known storage types (1, 2 and 3 for normal files, 13 for
directories), and rejecting anything else.

This takes care of the protection requirements for storage type 4.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand