12 Dec
2011
12 Dec
'11
11:44 a.m.
On 12 Dec 2011 at 9:26, Guy Sotomayor wrote:
It's even more general than that. Many folks have
fallen into the
Microsoft (FAT) limitation that a file is [char]+.[char][char][char]
format for a file name. Unix has no such restrictions.
No, and that's a weakness. As much as I'm not used to admitting
Apple superiority, the resource fork has a lot going for it.
I use MS-DOS a lot, mostly because I can get direct access to one-off
hardware on a time-critical basis without trying to squeeze an
implementation into someone's device driver structure.
I use the underlying DOS 7 that comes with Win9x and load the DOSLFN
driver to provide long filename support. While the system for
storing long filenames in a FAT is hugely inefficient, I do get to
call my files anything I like, as long as my application makes use of
the long filename DOS calls.
I believe that FreeDOS has long filename support built into their FAT
filesystem also. Essentially, then, the 8.3 DOS filename convention
only applies to pre-1995 versions of DOS.
And if you think that 8.3 is restrictive, try ISIS-II with 6.3
filenames and 4-character drive specifiers (e.g. ":F0:" for the first
floppy drive).
Long filenames are a pain to deal with when all you have is a command-
line interface. I can understand the approach of Unix and wildcards
to make the job a bit easier--although when you're faced with 10
files with 24-character names but for one character tucked away in
the middle of the name, wildcards require some thought to get to a
specific file.
------
Historical diversion:
On CDC SCOPE, files had a "local" name specific to a job and a
"global" or "permanent" name that was unchanging. One would
"attach"
a permanent name to a no-more than 8-character local name to allow
job tasks access to a file. Similarly, one could "save" a local file
to a permanent one by specifying a (up to 30 character, IIRC)
permanent name. Permanent file names also included a "cycle" or
revision number. Said files could even exist on archive tapes and a
job requesting such a file would be rescheduled until the appropriate
archive was made available.
There was no protocol to create a temporary file--one simply wrote to
one using a local name; said name was unique to the job session and
not visible to other jobs. At job end, local files not associated
with a pernament name or standard I/O device (e.g. INPUT, OUTPUT,
PUNCH) were discarded.
I think the system was an outgrowth of the tape handling system--a
tape was mounted during a job and associated with a local file name.
--Chuck