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."

11 of 102 comments (clear)

  1. what's wrong w/ 8.3? by toast0 · · Score: 3

    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

  2. Re:Because the Windows/WinNT File Systems still do by connorbd · · Score: 3

    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

  3. Re:Cross compatibility among heterogenous platform by DickBreath · · Score: 3

    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.
  4. Long Filenames by commandant · · Score: 3

    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.

  5. Microsoft Compiler by Anonymous Coward · · Score: 4

    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)

  6. I agree, but... by Adam+Wiggins · · Score: 4

    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.

  7. Re:OK by Matthew+Weigel · · Score: 4

    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
  8. Re:Why do we have /usr and /usr/src? by Phoukka · · Score: 4

    Um, for what little it's worth (about .00002 last I checked... :) "usr" actually stands for Unix System Resources.

  9. Re:Why do we have /usr and /usr/src? by AtrN · · Score: 4

    /etc == Edit These Carefully
    /var == Very Active Records

  10. Cross compatibility among heterogenous platforms by sporktoast · · Score: 4

    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.
  11. Speaking personally... by arnald · · Score: 5

    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