29 Aug
2006
29 Aug
'06
8:08 a.m.
Andy Holt wrote:
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]
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. 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...