From: sip1@ellis.uchicago.edu (Timothy F. Sipples)
Subject: Re: Using names instead of E: for drives
Followup-To: comp.os.os2.advocacy
Reply-To: sip1@midway.uchicago.edu
Organization: Dept. of Econ., Univ. of Chicago
Date: Wed, 11 Nov 1992 17:15:48 GMT

In article <1992Nov11.023401.3370@networx.com> mikel@networx.com (Mike Lempriere) writes:
>: I came to the OS/2 world from the Amiga and am really surprised that I
>: have to use primitive things like E: or F: to refer to volumes.  The
>You're right.  OS/2 inherited several VERY BAD things from DOS.
>a)  The notion of the drive (ie. drive letters) as opposed to a homogeneous
>    file system with drives grafted in whereever desired.
>b)  The "8.3" filename limit.
>c)  UPPER CASE FILENAMES.
>d)  No concept of links (multiple filenames for a single data group).
>All of these are filesystem problems.  Items b) and c) have been addressed
>by HPFS, although items a) and d) were completely ignored.  Item b) is still
>not really fixed by HPFS, as one must (basically) stick with the damn "8.3"
>convention if one may ever use a floppy (eg for backup!).

Well, actually, item (a) is addressed by a lot of networking software,
when something other than drive letters is critical.  Item (b) doesn't
hold for floppies -- if you use the Workplace Shell drive objects,
OS/2's BACKUP program, or most other system utilities (with the
notable exception of COPY from the command line), the long filenames
are preserved across transitions to/from floppies.  The reason
floppies are not HPFS is (1) there's no performance gain (in fact
there might be a performance/space penalty because of fixed overhead);
(2) DOS compatibility (can you imagine the nightmare caused by people
taking OS/2 floppies to DOS systems and wonder why it isn't working?).
Of course, this issue has been beaten to death, but you should
understand that there was a reason for the decision.  (Incidently, if
someone would like to write a REXX script to implement long filename
preserving COPY...  It is relatively easy to do.)

Item (c) is solved by HPFS, which is case retentive (but not case
sensitive).  I think such an organization is the best choice, but
others may differ (notably those with exposure to Unix).  It is
certainly the most user friendly, I think.  This issue, too, has been
beaten to death.

Item (d) is not implemented at the file system level, I agree.  But
IBM sees things evolving away from that level (the command line COPY
and DIR) and toward a GUI shell (and more friendly user interfaces).
I tend to agree with that assessment.  The Workplace Shell has what
are called shadows, which serve a very similar function, but at one
higher level of abstraction.

There's certainly the provision for such things as links at the file
system level.  It would be relatively easy to imagine such a system
operating with extended attributes.  (A link might be a null file with
an extended attribute pointing to the original, and the original
having an extended attribute pointing to the first link, like a linked
list.  Cumbersome, I suppose, but it would work.)  Of course, the
shell would have to be designed with links in mind.  But, then, that's
my point -- the Workplace Shell is already designed with links (i.e.
shadows) in mind, using the extended attributes already provided at
the file system level.  (Extended attributes are sort of a generic way
of implementing all of these specific niceties.)

To carry this a bit farther, one could imagine using extended
attributes to implement an on-the-fly disk compression scheme, version
numbers (like VMS), or many other features.

Follow up to comp.os.os2.advocacy.

-- 
Timothy F. Sipples      | The OS/2 FREQ. ASKED QUESTIONS LIST 2.0g is avail.
sip1@ellis.uchicago.edu | from 128.123.35.151, anonymous ftp, in /pub/os2/all
Dept. of Econ., Univ.   | /faq, or from LISTSERV@BLEKUL11.BITNET (send "HELP")
of Chicago, 60637       | [You picked the right President, America -- Thanks.]
Newsgroups: comp.os.os2.misc