Slashdot Mirror
Why Are We Still Using 8.3 Filenames?
FreekyGeek writes incredulously: "Here's a simple question: Why the heck is everyone still using 8.3 character file names for everything downloadable? We don't use 8.3 filenames for our own stuff. Every Real Operating System, and even toy GUI shells like Windows now support long file names. So why are we still using a filename convention that's almost 20 years old? Why do we have to deal with hard drives full of files named 'vcd43bup.exe' instead of 'Video Card Driver Update version 4.3 -- English'?" So can we really get rid of them?
"Who can remember those cryptic names 30 minutes after downloading them, let alone three months later? Are there still enough people out there using Windows 3.11 that we need this?
I suggest that as an industry, IT just decides 'It's time to move on from 8.3.' I mean, come on. This is ridiculous."
Most my downloads use "long" filenames-- "foo-1.3.2.tar.gz" is definitely not 8.3.
/etc instead of "/configuration", /dev instead of "/devices", /usr instead of "/user", and /bin instead of "/binary"-- convenience and usability (from the developer perspective, at least).
But it's a far cry from "Foo Source - Devel 1.3.2". And I'm actually rather glad that the file names aren't excessively verbose.
Why?
Because it'd be a real bitch to type tar -zxf Foo\ Source\ -\ Devel\ 1.3.2.tar.gz when I go to compile and install the package. It's also part of the same motivation that led to
Don't get me wrong, I *do* think that the 8.3 limitation is stupid. But let's be careful not to be overly descriptive. That's what INDEX and MANIFEST files are for. Don't make me type a 300-character gzip command for a stupid package, please.
I'm saddened that such a stupid troll got moderated up. I've got several friends who also use OS/2, and I've got several co-workers (at a Unix shop) who also use Macs, not counting all of my student friends who benefit from Macs. I only know of a couple of people who use BeOS, and in fact, I think that BeOS overall isn't very interesting - but they nailed the filesystem, and the file typing system.
The point is - and I'm saying this for the benefit of moderators who think that you are an insightful person - that it's not important how successful these other operating systems are/were. If we're not copying Windows (OK, Gnome is trying), then we're either striking out on our own without any idea of UI design, or we're trying to copy from other people with good UI design skills - like the MacOS, OS/2, and BeOS developers.
--Matthew
Hey, I didn't say it was perfect!
My point was that you can download files and they will be assigned reasonable file types without user intervention.Over all, I think that MacOS's 4-char type and 4-char creator attributes suck, but at least it's not tying the file type to the file name like Windows.
--Matthew
Maybe since then Mac has figured out MIME types (or a functional equivalent) and the concept that data is often (should generally be) seperate from the application that created it. It's more decentralized as Mac did it -- any application is entirely free to create new types as it wishes, and it is implicitly registered to handle the type -- but I like centralization sometimes. And application/x-whatever works fine anyway.
In other words, if you don't like the cryptic filenames given to you... rename them! Save v08fsjlse3.exe as "OEM Video driver beta 0.8 (feb 2000).exe" if you like. The renaming police won't lock you away for it. (Yet!)
Chu vi parolas Vikipedion?
So does ksh's file completion....
/home/mark/PERSONAL/
#>ksh
host:#>ls -d ~mark/PER*<tab>
(expands to)
host:#>ls -d
This space for rent. Call 1-800-STEAK4U
Actually, you can make ISO9660 CDs with 32-character filenames. The 8.3 convention is only for MS-DOS compatability.
I burn all my ISO9660 CDs with the long filenames, since my DVD player is happy with them and will display them when playing MP3s (otherwise I have to use some obscure Romeo extension). Of course, with Joilet and Rock Ridge, I never see the short 32-character names on my computer.
A fair number of 'us' haven't been using "8.3 filenames" since we started computing back in the eighties. The only place I have ever been forced to deal with "8.3", as you correctly point out, is on certain, particularly benighted, file repositories that either cater to, or run themselves, a certain, unmentionable, glorified program loader from a company in Seatle.
The main reason that we can't get rid of such trash is backward compatability: any file wandering across the net must be named in such a way that the system supporting the shortest maximum filename length can store that file, even if only momentarily. This is the same reason that we have uuencode and base64, and that various kinds of file metadata (unix permissions/ACLs, VMS generations, Macintosh resources and creators/types, etc.) don't travel well. Without some form of encoding all these nice extra bits get stripped off as soon as they pass through a system that doesn't know what to do with them.
BILL_GA.TES S.AYS IT._IS W.HAT CONSUM.ERS W.ANT
/. Lameness filter says I am using too many caps. :-)
:-)
I.CAN R.EAD T.HIS P.OST PERFEC.TLY
CAN.YOU
Well, the
Guess I'll have to fill up this space with more uncapped words so my comment will post.
Quando Omni Flunkus Moritati
If *I* was using emacs, I'd also need something to help me attain inner calm! ;)
It's only software!
...8.3 bashing while Unix uses /usr /etc /var /bin /proc /boot /home /root /sbin /dev /lib /tmp. The longer ones would be more descriptive but there are good reasons for shorter names.
-Docvert converts MSWord to OpenDocument, clean HTML
In a world of tools that do one thing and do it well, there's a very good chance that the program I want to run on that file is not the one that created it. It's thoroughly understood that I will want to run several different programs on any one file - no one program is regarded as having any more rights to the data than any other.
In the "so easy a gorilla can work it" world of certain GUIs, it's assumed that I will only ever want to access that file with one program. It's possible, but rather roundabout, to do otherwise - in fact, I'd bet that many users have no idea that a file could be opened with another program. The assumption of "one file, one program" means that each program has to be able to do everything that you would ever want to do on that file, leading to hideous bloat.
This end user would appreciate it if "experts" would stop declaring what he should find intutitive. B-)Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
See, that's just it - you don't know. You know what they wanted to open it with last time, not what they want to do with it last time. Do I want to render that HTML? Edit it? View it's source? Grep it? Spellcheck it? Do a wordcount?
Data is data, and tying it to one specific program can be extremely annoying to a user with a reasonable amount of sophistication. In fact, it encourages poor application design, where each application has to try to do everything you might want on that data and thus ends up doing it poorly, and proprietary data formats, since each type of file only will be manipulated by one program.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Well, maybe you have a directory full of fruit instead of files! Then "Fruit Basket" would make sense next to "Program Files"
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
Prevent email address forgery. Publish SPF records for y
Prevent email address forgery. Publish SPF records for y
Okey dokey. I put a preformatted floppy in my 1998 PowerBook, OS 8.6. Copied the file "three monkeys.jpeg". Took floppy to a Dell desktop, Win98. Long file name is just fine. Copied the file "parental-controls.gif". Took floppy back to the Mac. Both file names were retained just fine. (31 character maximum, of course, until March 24th.)
That said, there is one area that long names get screwed up -- ISO 9660 CDs. HFS, Joliet, and Rock Ridge all store their long file names differently. Very few CD burning packages are triple compatible, so anyone left out usually gets stuck with 8.3 names instead. There's a freeware fix for Mac though.
See, that's just it - you don't know. You know what they wanted to open it with last time, not what they want to do with it last time. Do I want to render that HTML? Edit it? View it's source? Grep it?
Mac solves this problem nicely. Every file has a type and creator field. Type indicates what kind of data the content is. Creator indicates what program to open the document with. Simply double click a document, and it opens with the application that created it.
You can always grab a document and drag it on top of a different application and drop it there (drag-drop) to open a document with a different application. The different application only cares about what type the document is, not the creator. If the type is, say, jpeg, it doesn't matter what program created it. Some programs will display it. Some programs will edit it, etc.
You can always change the type or creator of a file. (Usually you leave the type alone.) It's about as easy doing a chown/chmod type operation, albeit graphically. End users don't have the tools to do this. The way that end users change the creator is to open the document in a different application and then save it. The saving application stamps it with it's own creator signature. To change the type, again just open it in a compatible application and save it as a different type. For instance, open an Excel 5 file, save it in Excel 2 format. The filetype changes -- but so does the content. If I open a JPEG file (created by Netscape, and having Netscape's creator) in Photoshop, and then save it, the type doesn't change only the content. If you didn't change anything, and if the application is smart, it doesn't actually "save" anything, it merely changes the file creator. Sadly, in practice, implementors just go through the entire motions of saving the document, since computing power is so cheap.
To an end user, these operations are intuitive side effects of the way applications naturally open and save documents. If I created a file in Photoshop, then it gets photoshop's creator and opens in photoshop -- unless I drag-drop it to a different application. But other applications know whether they can even open it or not based on the type.
And best of all, no filename extensions.
Think of the document as a noun. The application as a verb. Grab the document drag it to whatever application you want. This is how you signify that you want to edit it, render it, etc. in a different tool. Apps stamp type/creators into documents to keep everything straight automagically. When you double click a doc, the desktop cooperates by launching the right app based on the file's creator -- NOT the file's type.
Filename extensions can only indicate a mixture of type/creator. Sometimes you think of it as creator, sometimes as type. But the two concepts are muddied together.
I call this great application design. It allows me to do sophisticated things with my data. But the system keeps everything straight and does the right thing when I want to do simple things with my data.
If a file doesn't have a type/creator -- as is the case when it came from a different OS -- then the file displays a generic icon. The file extension is then used to lookup in a user-editable table to assign the type/creator from the extension.
Unfortunantly, I don't think we'll see such an elegant system on my new favorite system because it would require (a) a filesystem to have type/creator fields, and (b) a major desktop environment to make use of these fields.
Command line tools don't care about type/creator -- just as in the case of Apple's MPW command line tools on Mac. Although CLI tools can pay attention to type/creator if they want to. For instance, a CLI mp3 player could be smart enough not to play a file whose type says JPEG or HTML.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
I'm not on Linux (I miss tab completion the most), so I can't grep for it
If you use Red Hat Cygwin (GNU software for Windows) or the full version of DJGPP (GNU software for DOS), you get bash and grep.
Back on topic... lack of tab completion in the WinDOS distributions is what keeps us using easy-to-type 8.3 names.
All your hallucinogen are belong to us.
Will I retire or break 10K?
The other reason why no one has dropped 8.3 is that everyone is doing LFN differently. OS/2 can not read Windows LFN, Windows can not read OS/2 LFNs. No need to bring Apple into it.
Mac OS 8.x supports Windows 9x's VFAT long filenames on FAT filesystems.
The other irritating feature is that LFN is supported when the GUI is loaded. You can not fix a LFN from a Win9x boot disk.
Typical Microsoft practice of tying various things to their OS (in this case the GUI). You can add LFN support to DOS with LFNDOS. Works for LFN-compatible DOS programs such as command.com 9x, edit.com 9x, and all DJGPP programs.
All your hallucinogen are belong to us.
Will I retire or break 10K?
n.3 naming is rather useful from time to time. My site is at GeoCities and I use .tgz on a lot of my files because GeoCities' filesystem is kind of screwy. But even then, it seems to be a mere artifact of the web-based site admin tools and .html suffixes work just fine.
My $.01 (it's not worth that much),
/Brian
I had a Windows system that went toes-up on me--apparently a virus had clobbered some of the Windows core executables and the system refused to boot. Reinstalling Windows on top of the blown image didn't work. Even booting from floppy disk failed. The Command-line-only mode gave me only the 8.3 file names, not the longer file names.
The solution? Move the blown hard drive to a Linux machine, and use the VFAT FS support to read all the Windows files. Write a CD-ROM with everything that needed to be saved. Then blow away the hard drive image completely using the Linux utilities, and reload Windows and all the apps completely from scratch onto the now-clear hard drive. (This also meant I had to blow the partition table away, but that was small loss.)
It's even easier if you have your system dual-boot with Linux, so that when Windows eats itself for lunch, as it seems to do every six months or so, you have a way of saving off all those files you would otherwise lose. Linux makes Windows palatable.
Now, isn't that ironic?
As to the part about long filenames, I have to wonder if this is a troll?
You are entitled to your opinion. I hope you enjoy comming up with 8 character filenames.
I think your example is a little extreme. Surely there is a balance to be struck, such as naming the file "Phys. Lab Writeup 3-Mar-2001".
As to the other part, suggesting that three characters are enough for identifying what viewer/editor to launch, I can only say this. (Not against you, btw. Just in general.) Maybe someday, someone will have a stroke of genius and re-invent the Mac's Type/Creator system for other OS's, freeing us from filename extensions. Maybe they'll improve it by using MIME types for the type system. I can only dream.
I'll see your senator, and I'll raise you two judges.
limiting yourself to 8 characters for a name prevents you from creating attrocities
:-)
One more thought.
Maybe you should get a special version of Napster, Gnutella, Freenet, etc. that only shows you 8.3 filenames for the result of a search.
Hey! Maybe if everyone gets creative and starts using 8.3 filenames, this will defeat Napster's filtering efforts. (Okay, now I'm just being facetious.)
And... this is not a flame.
(It's really sad that I have to say that for the fsck'ing moderator's sake.)
I'll see your senator, and I'll raise you two judges.
OS/2, MacOS, and BeOS all solved the 'file extension/file type' problem a long time ago
I don't know how OS/2 or BeOS solved it.
I daresay, in all cynicalness, that such a solution would not be accepted well on Linux because it goes against longstanding traditions of making systems difficult to use.
Okay, yes, this message is a flame. But not against the message it replies to. I'm just frustrated at the moment. Okay, maybe not a flame, but a troll. I ordinarily never write trolls, so I guess I'm overdue. (But I am trying to express an opinion.)
I'll see your senator, and I'll raise you two judges.
I too sometimes wonder about 8.3 filenames but I think my subject is one of the reasons, it's a convention... old habits die hard
Also, I find that when I'm working in a dos/win environment that I spent about as much time on the prompt as I can, and all that ~1 crap gets annoying if I go over the 8 chars.
Taking a look around the office right now we're running: W2k, Linux, W98, NT4, OS/2, and W95. Some of the winblows boxes still run old 16 bit apps that get kinda cranky when presented with long filenames. I think the reason 8.3 is still around is that it's a convention, it's not better (and in some ways is worse) than any other convention, it's just that 8.3 has been used since the days of DOS and everybody's used to it. I really wouldn't mind seeing it go, but at the same time it's a bit of an unofficial standard and will likely remain so for quite a while, at least as long as M$ dominates the desktop.
Actuaries - making accountants look interesting since 1949
All I usually type is 'tar zxvf gcc-c' then hit return. There could be 50 characters more to go, but the shell will just fill them in.
Oolite: Elite-like game. For Mac, Linux and Windows
I can still remember teaching my brother how to use the word processor on our old Apple IIGS. He had started working on a document, and wanted to save it, so I showed him how to select 'save' from the menu. When prompted for a name, he asked what he should call the file. I told him to call it whatever he wanted. Thinking himself funny, he called it 'bob' After a few months of naming files that way, he wanted help opening a file that he created a while ago. We started the word processor and tried to open the file. We got to the directory where he had been saving stuff and found it full of 'names' He couldn't remember what he had named the file; was it frank, suzy, thomas, henry, etc? I can still remember his comment. "Oh, I guess that wasn't such a good idea."
My point here is that if you can't easily tell what a file is by looking at its name, the naming scheme is flawed. 8.3 can be restrictive in that manner, although the extreme other end (ie 'this file...foggy day.microsoft word') isn't that great either.
On FAT volumes, MacOS versions prior to 8.5 thunk their own 32-character (semi-long, you might call them) file names down to 11-character file names with an exclamation mark included as the first character. A dot is inserted between the 8th & 9th characters. Spaces are dropped, and the case distinctions are lost. Extensions are (usually) kept, if a dot is in the original name (though multiple dots in the original name produce odd results). Name colisions are solved by replacing the last character (even in the extension) with a numeral, starting with 0. Info about the original MacOS semi-long name is kept in one of the semi-invisible support files created (Desktop DF, Desktop DB, Resource.frk, etc.), not sure which.
(Interestingly enough, MacOS does manage to give properly formed long file names to several of it's necessary resources: "___Move&Rename", "AppleSharePDS" and "OpenFolderListDF_".)
The following list of files, together in order of creation, shows MacOS name thunking results:
Files created on Win9x as viewed on (pre-8.5) MacOS will show the usual thunking pattern ("MYCOOL~1.DOC") that we've all come to know and hate.
In a related story, the IRS has recently ruled that the cost of Windows upgrades can NOT be deducted as a gambling loss.
Most Windows users have the "hide extensions for common file types" thing turned on, so they never see extensions and in my experience have no idea what they are.
This is worse than with the Mac: Mac users who know what's up can go change the Type/Creator as they please; the rest use the intuitive methods described by another poster above.
In Windows, on the other hand, you have the extremely annoying situation where any one extension is hijacked by a particular application. If you have three HTML editors, and you work on different projects in different editors, you have to manually select the application EVERY DAMN TIME you open one of the files. Furthermore, the extension-space is so limited, crowded, and poorly adjudicated that various applications are always stomping on each other's extensions. Photoshop and Visual Studio are particularly egregious examples; each of these, when installed, registers itself as being responsible for about half the namespace. Worse yet, they both register various types that overlap, even though they are COMPLETELY DIFFERENT TYPES OF FILES.
To sum up: Windows is unusable.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Three characters is not enough, there are plenty of programs that use the same extention.
What is annoying is that windows can implement something very much like Mac's way of doing it, very easily.
It already does something like this on Office documents, and that is on 9x.
On NT, it's simple matter of creating a resource fork, and since NTFS support unlimited number of streams, it's a trivial matter to check on who owns this file.
(Basically, if the resource is empty, you go by file extention or ask the user, afterward, you already knows what the user wants this file to be open with. So you store it in the ADS)
--
Two witches watched two watches.
Which witch watched which watch?
three characters is plenty for determining which viewer/editor to use offhand, and limiting yourself to 8 characters for a name prevents you from creating attrocities such as 'this file is a document which contains the bulk of my work in the physics lab writeup for the lab i completed on march 3rd of 2001 which incidentally was a foggy day.microsoft word'
consider the precis (i think it needs an accent) from your english composition class, the idea was write a summary of the work in 30 words, no more no less, by giving yourself an artificial constraint you have to be more creative (or something).
there is nothing stopping anybody from using longer names for most things, they just don't feel the need. a good nested directory structure can help determine what the file is about, and some kind of title in the file itself doesn't hurt
Need a Catering Connection
I seem to remember somewhere having heard that the way to handle long filenames in Windows (recommended by MS) is to create an 8-character prefix to the filename and then put your real filename after that. Great idea, especially when Microsoft's idea of long filenames in VFAT is to allow a total pathname length of 255 characters.
It's called bug-compatibility. On the one hand, it means you can still run a 1981 version of Visicalc (free for download from www.bricklin.com) on Win2K. On the other hand, it means you're stuck with bad design that should have been excised long ago.
/Brian
I haven't tried your actual experiment, it will have to wait until tomorrow.
I routinely get from an outside contractor FAT formatted ZIP disks containing long filenames, and my Mac sees them just fine.
Mac OS 8.5 introduced long filename support for FAT volumes. I've used it plenty of times. So I can at least say that bringing a long filename from Win -> Mac works. I'm pretty sure about the reverse.
If you use Mac OS prior to 8.5, then Mac OS will only use 8.3 filenames on FAT volumes.
In fact, before I ever used Linux, the Mac OS was the only computer I knew of that could read/write and format a number of non-Mac volume formats.
As for CD's, they only seem to come in Mac HFS or ISO 9660. The ISO format may have various extensions (Joliet, Rock Ridge) which are not recognized by Apple's plug in ISO filesystem module. There is a third party free (beer) module that does recognize these. (Again, don't remember, but the name Temple or Tempel comes to mind?) So you can also put in an ISO CD with Joliet or RR extensions into a Mac and see long filenames.
As an off topic aside, I routinely make ISO images on either Windows, Mac or Linux and move them to one of the other platforms for burning. (At home, I only have Mac + Linux, and burner is on Mac. At work I have burner on Mac, and high capacity duplicator on Windows.) I can even make ISO/HFS hybrid disks this way. I also frequently mount all kinds of foriegn disk image formats on the Mac using the Mac's equivalent of a "loopback" device. (i.e. DiskCopy Mount command.) My point: The Mac has had a lot of capabilities for a long time that only real OS's have, and which Windows is yet to have. So if you're not a long time Mac user, don't sell the Mac short.
This is not (intended as) a flame.
I'll see your senator, and I'll raise you two judges.
Funny you call Windows a "toy GUI shell" or something like that, and then go on to give a .EXE example. Furthermore, you give a filename that uses spaces, which are a bitch to type with quotes or escape sequences. A sure sign you depend on Windows and its graphical shell.
This makes it odd that you would knock it, unless you are just trying to fit in with the slashdot crowd. hrm...
A new year calls for a new signature.
I'm posting anonymously because I'm violating yet another NDA here...
Microsoft's internal compiler (the one they use to build their own apps) still can't handle filenames longer than 8+3. That's why all object files even in the latest version of Windows 2000 are still 8+3 (TASKMGR.EXE, XACTSRV.DLL, etc)
There's a happy medium in there somewhere wherein filenames are descriptive but not unreasonably long. Certainly I think that spaces are rather silly - it has long been a convention to seperate different "objects" with spaces, so even though you _can_ use them in filenames, I don't really think that you should. Especially when you consider that spaces aren't allowed in URLs, which have become almost as - or perhaps more - important than regular files.
For the file example you mentioned, I think the filename should be something like MatroxG400driverV4.3en.exe, although even that is pushing my limit on filename length.
Bzzzt, sorry. OS/2, MacOS, and BeOS all solved the 'file extension/file type' problem a long time ago, without the MS hack that leads to 'x.jpg.vbs' exploits in MIME clients. MacOS has the most consistent way of doing things (specifically for downloaded files), but they all handle it.
OS/2 (and possibly BeOS) also support command-line querying and setting of file types, and Unix has had the file 'magic' command for some time to identify file types based on their contents.
--Matthew
Try this:
Put a Wintel-formatted floppy (1.44M, ZIP, JAZ, LS-120, whatever) into a Macintosh. Move a long-named Mac file onto it. Bring it to a Windoze box, look for the file. Put a long-named Windoze file on it. Sneaker the disk back to the Mac. Look for the second file.
Post your results here.
In a related story, the IRS has recently ruled that the cost of Windows upgrades can NOT be deducted as a gambling loss.
Being a Haiku fan, all my filenames on Linux are in 5.7.5 format. I find it helps me attain inner calm whenever I have to use emacs to load a file. :-)
arnald