"File types"

[Don]

Andy Holt wrote:
>> Yes, I *know* this has been done other ways in the past.
>> What I am trying to figure out is the rationale behind
>> why it has (apparently) migrated into the file *name*.
> 
> That, I think, was a necessary side effect of the original Unix design
> decision that "a file is a sequence of characters" without special propertis
> that are known to the operating system.

IMO, a file *is* an untyped string of *bytes*.  The OS shouldn't
care about it's representation (none of this "text mode" vs.
"binary mode" crap).  It's "attributes" should solely be things
like size, creation time, ACLs, etc.

As the **OS** sees it.

The nonsense of "file types" belongs at a higher layer.
E.g., IMO the Windows/MAC/etc. GUI's are (read that as:
"should be") viewed/built as layers ON TOP OF the OS (from
a conceptual standpoint; implementation details may differ).
So, if that "presentation" layer wants to *impose* something
like a "file type", *it* assumes the cost of maintaining that
information and encoding it in some "sensible" manner.

[i.e. my issue here is why this encoding seems to have
gravitated into the file NAME instead of some other mechanism]

> As has been pointed-out DEC operating sytems going batck to DOS/BATCH 11 and
> probably earlier have used the (then) 6.3 convention. What might not be so
> well known is that for most mainframe operating systems of the era a lot of
> attributes of a file were stored, maintained, and _enforced_ by the
> operating system. This was especially true of the GECOS (later GCOS) system
> that the Bell labs people knew all to well.
> 
> So, as far as the OS was concerned, files might be serial, sequential,
> indexed sequential, random (and perhaps other organisations) with fixed or
> variable record sizes. (see the DCB card in OS360 JCL); there may be a

IMO, this was a mistake.  It forces the OS to know too much
about the applications that run on it -- instead of being a
resource manager.  I.e. it should implement mechanisms, not
policy.

> complex set of access permissions (not just read/write/modify, or even
> access control list, but possibly password-controlled access or time of day
> limited also); and there probably also are a large set of backup options as
> well.
> 
> These could make if very difficult, for example, to write a COBOL program
> whose output was source for the FORTRAN compiler [and even harder to do the
> reverse - COBOL, at least, could probably handle most file types)

Exactly.  Or, any "unforeseen" file types...