Re: Help! Filetype $00 problems . . .

[Randy Shackelford <shack@onyx.southwind.net>]

Jeff Blakeney <CUTjefbla@bconnex.net> wrote:

:>Every filename, from volume name to directory name to standard file name to
:>extended file name, is a Pascal string. That is, it's a character string 
:>preceded by a length byte. There necessarily is code to disallow renaming an 
:>extended file. If it didn't check, it wouldn't know the file is extended. It
:>does check and returns an unsupported STORAGE_TYPE error.

: The file name is not quite a Pascal string. The storage type and
: filename length are stored in the same byte.  That is why filenames
: are limited to 15 characters.  You can only have a length nibble of
: $0-$F (0-15).

Right, it uses four bits for the length and the other four for the storage
type. Still for all intents and purposes it's a Pascal string.

: ProDOS was created long before extended files were even considered.
: I'm sure one of the safety features in ProDOS is to not allow any
: access to storage types it does not understand.  If this is true then
: the code to disallow any access to extended files has been around
: since day one, before extended files even existed which means that
: they didn't ADD code to disallow renaming them.  This is what Dave was
: getting at.

Yep, my old Tech Ref Manual covering ProDOS 1.0 made it clear that all
undefined storage types were reserved for future use. They even built in
a way to support changing the directory structure and allowing old versions
to know not to try to access newer directories. That was to be done with
the VERSION and MIN_VERSION fields. Those exist on file entries as well.
Apple scrapped that idea and redefined those fields to hold bits denoting
lowercase characters in file names.

Since there is no distinction in file names on extended files, it has to
do some check on the storage type. If it blindly renamed files, you could
rename extended files just like any other file. I wonder, if you took a 
really old version of ProDOS which predates extended files and tried a 
rename, whether it would work. They could have designed it that way from
the get go but maybe not.

:>There are many operations which can't be done on a volume, but it is possible
:>to rename a volume. There is no excuse for not being able to rename an 
:>extended file. I bet if someone wanted to go to the trouble, they could
:>come up with a patch to make it possible.

: Yes, someone could patch ProDOS to allow it but it is my opinion that
: it is best left the way it is.  If you can't rename it then you
: automatically know that you can't copy it or delete it either.  In
: effect, you know it is an extended file.  Don't forget that ProDOS
: doesn't indicate an extended file in any way in a directory listing.

What you mean to say is that most apps i.e. SYS programs don't make a
distinction. Recall that ProDOS has no "catalog" built in as does DOS.
SYS programs are left to their own devices there. True, no common SYS
programs like BASIC or Appleworks display extended files differently, but
there's nothing to stop it. The version of ECP8 which I modified after
the source became public has a rewritten catalog routine that displays
a plus sign next to the file type on extended files. This is similar to
the ORCA shell for the IIgs.

: It would probably be easier if someone were to write new ProDOS
: external commands for renaming, copying and deleting files.  These new
: external commands could be written to work with both the standard
: storage types as well as extended types.

I wrote ECP8 shell programs to do plenty of stuff like that. One useful such
program was one which reads the data fork of an extended file and writes
the data to a standard file. I was working on a program to delete extended
files but never got the kinks out of it. Man I haven't touched any of that
stuff in many moons.
-- 
Offsite mail to this host gets nuked.