[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help! Filetype $00 problems . . .
- Subject: Re: Help! Filetype $00 problems . . .
- From: David Miller <xjustdavex@glis.net>
- Date: 1999/04/26
- Mail-copies-to: nobody
- Newsgroups: comp.sys.apple2
- Organization: Posted via RemarQ Communities, Inc.
- References: <7f7rnc$5ld$1@nnrp1.dejanews.com> <3717BE31.9D978677@swbell.net> <6YQR2.224$3F1.7847@news13.ispnews.com> <J3S7S+G.kws@delphi.com> <vb3U2.2005$2n1.105953@news12.ispnews.com>
- User-agent: YA-NewsWatcher/4.2.2
In article <vb3U2.2005$2n1.105953@news12.ispnews.com>, Randy
Shackelford <shack@onyx.southwind.net> wrote:
> kws@delphi.com wrote:
>
> : There is a tech note about this. ProDOS can't use up vast quantities
> : of memory, as some OSes do. Renaming a forked file shouldn't require
> : much extra code, but if you can rename it, why not read it, write it,
> : and create it, all of which *would* require extra code. Not allowing
> : renaming is absolutely stupid, though. Consistent, but stupid.
>
> Huh? If anything disallowing renaming extended files would take more code
> than allowing it. There is nothing about the filename field in a directory
> entry that's different from any other file. They had to put code in to check
> the storage type and disallow renaming an extended file while allowing
> it would mean simply doing the rename as with any other file.
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). Safer to just ignore anything with an unknown storage
type.