On or about Mon, 24 Sep 2001 21:08:50 -0600, Chuck Simmons
<[EMAIL PROTECTED]> allegedly wrote:
>The reason that Windows went to using the file suffix to carry metadata
>was because of a desire to eliminate any need for a powerful text shell
>for the OS. That is, the dialog to get a file open in the correct
>application is clumsy without command line interface if the file type is
>not identified in file name. On the other hand, the strong file
>associations create clumsyness in other applications. For example, I
>create on a Windows system where I work plain text files with a bunch of
>different suffixes. I can't use a .txt suffix for these files because of
>name overlap (the text file name indicates data content and the suffix
>indicates the exact format of the data). Dealing with this in Windows is
>clumsy. I did consider simply moving the whole mess to Unix where the
>clumsyness vanishes but current customer installed OS base makes that
>impossible. Thus I suffer and the customers suffer. (They seem cheerful
>in the face of it.)
I used to have that problem. I would keep contracts with a .CON
extension, letters as .LTR, and so on. Then I found that organizing
worked better and more logically using appropriately-named
subdirectories instead.
The problem I have with the Unix convention is that you have to check
out a file's properties to determine what sort of file it is. In
DOS/Windows, all you have to do is look at the file name.
--
Mike Koenecke
to reply, change "nowhere" to "home"
