On 8/28/2006 at 4:47 PM Don wrote:
No, those are file *permissions*.
Are you asking, "Did any system keep file type information out of the file
name?" The answer is "yes, several did". Here's part of a
microcomputer
floppy directory from a circa 1977 OS. Note that fiile dates show this
disk was probably created around 1986 (yes, it's all in ASCII--no binary
fields here):
A$DIRECTORY 000000001500000016 SF 064032386
ACONFIG.SYS 000160001610000016 DV 000010199
AMT.PARTS 000170001702700017 DV 000010199
ADX85M26D03 000180004643600046 LV 000080483
AISAM.SYS 000470005814400058 SV 000080483
A$AUTOSTART 000620006201300062 PV 000080483
ARUN 000630009348700093 SV 000080483
AMTMENU 001120013036800130 OV 000010199
ALOCATE 001310014242700142 OV 000010199
A$SBA.C 001430014400000143 II 003
A$SBA.C@ 001450014800000145 MF 055
First column is the file name, the second is the file allocation and length
information. The third column is the file type and the record type.
S=System D=data, L=boot loader, P=profile, O=binary object, I=ISAM index,
M=ISAM data (there are other types). The second characters is the type of
record F=fixed, V=variable, I=index. The fourth column is the record
length and the creation date. By convention, ISAM index files take the
name of the data file, with an "at" sign appended, though there was no
particular system requirement for this.
If you enter the name of a file that didn't have the O file type, the
system won't execute it. Similarly, you can't open a file with anything
other than the DV attributes for text display or editing. ISAM files are
handled by the ISAM manager and nothing else. You can't do ANYTHING with S
or L type files, not read them, not write them directly.
I've seen other systems from the 70's with this kind of directory
information. However, the idea of a file extension for certain types of
files was contagious--note the CONFIG.SYS (well in advance of MS-DOS).
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*.
Valid (though silly!) arguments could include things like:
- portability (file system independance)
- efficiency (no need to have extra atributes *in* the file)
- The Evil Empire couldn't come up with anything more original
- "Just Because"
I.e. if you were starting from scratch *today*, why would
you chose to encode file types in file names? vs. some
other alternative??