(Excerpts from a message dated 11-09-99, Mike Ruskai to Murray Lesser)
Hi Mike--
ML> I am sure that you can write such a program (using existing OS/2
ML> APIs), there is no necessity to do so. Unless, of course, you
ML> don't like mousing around the desktop and do your serious computing
ML> from the command line. In that case, you probably don't use long
ML> file names, no matter which file system you are using, because they
ML> are a nuisance to enter from the keyboard.
[snip]
MR>I'm one of those people who don't like mousing around, but I also
>like long filenames. Any inconvenience in typing them (I'm a fast
>typist, so it's not much) is small compared to the annoyance
>experienced when trying to figure out what 8.3 name was used to name
>something that would be easy to find with a sensible longer name.
MR>4OS2 duplicates the WPS behavior you describe in the snipped portion,
>creating the .LONGNAME attribute, and using it for the filename when
>the file is copied/moved back to a HPFS drive.
[snip]
MR>You should probably give 4OS2 a try.
Thanks, but no thanks. I do not like such substitute command-line
utilities because I can't be bothered to learn another command language
based on someone else's idiosyncrasies. If I wanted such a utility I
would write it myself, so it would be based on my idiosyncrasies :-).
Rather than a kit-of-tools approach, I write individual utilities (in
PL/I or in REXX) that mechanize those individual tasks that I do
frequently. Seems to work for me, but I would never recommend this
approach to anyone else. Using one's own computer is a very individual
thing, and what works well for me would not necessarily work for you.
In any case, I have never had the necessity of copying a file from
HPFS to FAT, preserving the long name. I was merely telling Eddy
Thilleman how to do it, in response to his posted query. So the only
time I have ever played that game was with a dummy file having a long
name that I set up to make sure that I knew how to do what I was telling
Eddy to do, before I told him.
As far as my own computer usage is concerned, I've never had any
trouble in finding an 8.3 file (I had written) that I wanted later. I
use subdirectories, rather than long names, to categorize files. For
example: Copies of all my outgoing correspondence for the year are in
an HD directory named "CORRESP" and each file name is made up of the (up
to) eight characters of the recipient's name, followed by an extension
of three characters coding the date. There is also a file in that
directory named CORRESP.SUM, that carries a brief summary of each of the
other files in the directory. Come December 31, I print the contents of
CORRESP.SUM and file the printout in a notebook. I then zip the
contents of that directory (filename: YYCORRES.ZIP where "YY" is the
last two digits of the year in question) and archive the zip file to an
Iomega Zip diskette, after which I wipe out the CORRESP directory
contents and start over.
This is a very small part of my year-end system housekeeping tasks!
There are a lot of home-grown date-sensitive record-keeping programs
that must be modified and recompiled for each new year. Each such
program lives in its own subdirectory, along with all of the record
files it is keeping (the backups are on floppies). The past year's
version, along with its data files, are also archived to that same Zip
diskette before deleting the HD directory they had been in.
So, it doesn't take much effort to find any piece of outgoing
correspondence written at any time since 1984, when I started this
procedure. (Note that "long file names" were not available in 1984.)
All early versions of the record-keeping programs since 1988, along with
the records it kept, are also easily available from the same Zip
diskette. None of them need long filenames to find, and none are
wasting space on my hard drive. (I archived to floppies until I got the
Zip drive a few years ago. Things are much easier, nowadays.)
As you see, I can find no reason for me to use long file names, so I
don't.
Viva la idiosyncrasy :-),
--Murray
___
* MR/2 2.25 #120 * Happily hitchhiking on the Information Highway
--- Maximus/2 2.02
* Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)
|