Why Are We Still Using 8.3 Filenames? 102
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."
Re:OK (Score:1)
NAME one PERSON who USES BEOS. NAME 10 people YOU know THAT use MACOS. NAME one WHO ever TOUCHED OS/2.
YOURSELF does NOT count
/. anyone? (Score:1)
.htm Extension Considered Useful (Score:1)
Re:tab completion and grep in DOS and Windows (Score:1)
Tweak UI is free and from MS: http://www.microsoft.com/ntworkstation/downloads/P owerToys/Networking/NTTweakUI.asp [microsoft.com]
ridiculously long filenames are ok but no spaces (Score:1)
Because that has spaces in it and spaces suck...
ridicoulousy long filenames are sometimes a pain in the ass. i think you example is a little to long. I appreciate longer than 8.3 but not that long and no spaces. plus how downloads
because its an ISO (Score:1)
its a standard why stop useing IPv4 ?
iso9660 ring any bells ?
thats why and umsdos is better bet than vfat because I dont have that compiled in (-;
regards
john jones
Re:what's wrong w/ 8.3? (Score:1)
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.
Hmmm... I think you might be confusing CLI design with GUI design. Let me explain.
Taking your HTML example, it's handled on my Mac system in this way: The HTML files that I am editing all are "owned" by my text editor. When I want to check out what I did, I open the HTML file from within Netscape. Any HTML file I have that I'm not trying to edit is typically owned by Netscape. So, I have exactly the behavior I want for editing or viewing HTML. Double clicking a file does what I want/expect in each case.
Your other three examples really don't fit the GUI mentality. Grepping? Why would grepping care what program is set by default to open the file? It should search all the files you specify in the regexp. As for the last two, Spell check and word count, in a GUI environment, you typically do those inside your editor. Usually there's no GUI utility that you'd only spell check or only word count with, the way you would in a CLI environment. This is counter to the Unix philosophy. Well, that's the GUI for you, and that's why I like also having the CLI as an option.
I disagree that this creates more proprietary file formats. My graphics programs all handle .jpg .tif .gif .pict .bmp and whatnot. Source code is still all text, just with different types and creators. An MP3 is an MP3 whether MacAmp (or something else) owns it. Where's the proprietary formats? Its predominantly microsoft that goes off and pulls that crap.
I do agree that this encourages each app to implement its own "search" function on its own. However aren't CORBA, libraries and whatnot supposed to allow any app to use a uniform search function that someone else wrote for you? Of course, that's only good if people actually use it.
Personally, I find the MacOS file type method to be the most flexible method I've ever used. BeOS used a similar scheme, only it used the MIME type; it behaved much the same way. Certainly, it's infinitely more flexible than the windows method, using only .xyz extensions to determine ownership. There, .html is ALWAYS a Netscape or IE file, and you have to work extra to treat it any different way. This always annoys me.
I guess my feeling is, the MacOS has it right, when it comes to the way file types are maintained, from a GUI point of view. Your other objections can be taken care of by using the command line the way you clearly want to. The MacOS has never had that option up until MacOS X...
hmmm, hope all that made some sense... :)
--Thad
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re:what's wrong w/ 8.3? (Score:1)
I suppose it's not "intuitive". But it is more flexible than the win32 way, and it is set up exactly how I want it. :) Anyway, the icon changes depending on what app "owns" the file, so I can instantly tell which program will open a file, by default, just by looking.
Well, it doesn't fit the standard GUI mentality of today's systems - but I submit that said mentality is badly broken in several ways. It is not, as is so often claimed, intuitive; it's limiting; it's inflexible (no, "skinning" is not flexibility).
Well... I think the basic operations of current GUIs are reasonably intuitive, once you've learned some basic rules. (double click, etc...). But yeah, I'd agree that GUIs aren't as flexible as they could be, and the fact that my mom -still- needs help copying a file to a floppy disk after 8 years using her Mac shows that there's plenty of room for improvement.
Basically, with all its faults, I still find the MacOS GUI to be the smoothest "desktop experience" out there, esp. when compared to the clunky win32 interface... I have high hopes for MacOS X. MacOS quality interface (hopefully better, but that remains to be seen) WITH a Unix command line. To me, that's about the best I can imagine...
Old Radio Shack Color Computer eh? Suppose I should get out my old Vic20... wonder if my cassette tapes still hold the programs I wrote when I was 7... or if I can remember hot to retrieve them! :)
--Thad
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re:Cross compatibility among heterogenous platform (Score:1)
=)
Zetetic
Seeking; proceeding by inquiry.
Elench
A specious but fallacious argument; a sophism.
Re:what's wrong w/ 8.3? (Score:1)
Since BeOS keeps attributes for the files (such as type), when you right-click on a file it'll give you a list of all the programs installed that handle that file type.
Seems to work well for me...but then what do I know.
Re:what's wrong w/ 8.3? (Score:1)
So some HTML files are "owned" by your editor, others by Netscape. Not at all what I would call "intuitive".
Well, it doesn't fit the standard GUI mentality of today's systems - but I submit that said mentality is badly broken in several ways. It is not, as is so often claimed, intuitive; it's limiting; it's inflexible (no, "skinning" is not flexibility).
Or maybe I'm just feeling especially curmudgeonly today. Maybe I'll go dig up that old Radio Shack Color Computer when I get home...who needs a GUI or CLI when you've got BASIC built right in? B-)
Tom Swiss | the infamous tms | http://www.infamous.net/
Why use them at all? (Score:1)
Re:Because COMMAND.COM sucks (Score:1)
Re:I agree, but... (Score:1)
Re:Why do we have /usr and /usr/src? (Score:1)
I assume that etc means "et cetera", but if that is the case, why are the most important system files placed in a directory named for misc stuff???
Don't want to guess what /var stands for.....
Trains stop at a train station. Buses stop at a bus station.
More blatent Microsoft hatred regardless of facts (Score:1)
Re:what's wrong w/ 8.3? (Score:1)
I _hate_ it when programs act as if they know what I want to do all the time. If I want to edit a file in some other way than it was created, it should be easy to force the OS to open it up in whatever I want, and not treat it differently.
Re:what's wrong w/ 8.3? (Score:1)
I forget how 'doze comes stock sometimes...
Re:If you don't like the 8.3.... (Score:1)
I've switched to Linux.
I still don't like 8.3 filenames. I don't find myself limited to 8.3 in Linux. Why not switch to Linux if you hate 8.3?
Extensions still needed under Windows (Score:1)
¹Don't use command.com. Use Bash instead. (Score:1)
Go ahead. Just _try_ tab completion or ad[vV]anced.{glob,pattern}s on MICROS~1.
I just did. It worked. Know why? I use Bash instead of command.com. A good version of Bash DOES exist for both DOS and Windows (see my earlier comment #41 [slashdot.org]).
All your hallucinogen [pineight.com] are belong to us.
well (Score:1)
Re:One word.... (Score:1)
A master list of document types and the programs that run them.
Windows would do well to disolve the registry, it is pure bloat. and if somebody tris to tell you linux
Defrag (Score:1)
Because COMMAND.COM sucks (Score:1)
Go ahead. Just _try_ tab completion or ad[vV]anced.{glob,pattern}s on MICROS~1.
Also, Linux lowercases 8.3 names, but VFAT ones are case-sensitive. So 8.3 is inherently superior (I'd like my Amiga back, please.)
DOS floppies (Score:1)
DOS boot disks are not the sort of thing you carry around in your purse...
Oh, sure, now they tell me... I carry DOS floppies with System Analyzer [shareware]--that's the only program that's ever seen my system as a Duron. Very nice.
(The purse in my case is strictly notional.)
Re:tab completion and grep in DOS and Windows (Score:1)
Open up regedit, search for "CompletionChar", change its value from "0" to "9". Open up a dos prompt type "cd " and start hitting the tab key.
It isn't anywhere near as good as bash, but works with long filenames.
You can also do something similar to grep from the any explorer windows using the right click menu. Do a find, use the advanced tab and you can put in text to search for within documents (again, not as good as grep, doesn't do regex)
Re:Why do we have /usr and /usr/src? (Score:1)
ALL YOUR BASE ARE BELONG TO US!
Just buy a Mac. . . (Score:1)
However, any professional IT person who is primarily a Mac user can tell you that when they sit down in fornt of a windoze pc the agony of attempting to decipher what the hell is going on is generally derived from the fact that nothing is named in a way that eases system maintenance.
It is not just the Mac's physical interface that makes it superior to the windoze pc, but the underpinnings. Open up the C:/WINDOWS/ folder and try to figure out what is what from the extremely cryptic setup. Now open the Macintosh HD:System Folder and look at that! Real-world naming! What a concept! I shouldn't have to learn how the OS was made in order to figure out how it works. With a pc, you need a stack of manuals, books, etc, to figure out how to be effecient. With a Mac it's just common sense.
So buy a Mac, and enjoy.
Re:OK (Score:1)
Re:Hmm... (Score:1)
Re:Extensions still needed under Windows (Score:1)
Re:Wise up ! (Score:1)
Let's keep
Ian
Re:Wise up ! - oops (Score:1)
Spill Chucker failure I'm afraid.
Ian
Re:OK (Score:1)
Yes, because in Windows you do all of this with Visual Studio... no need to fool with multiple programs to do different things!
---
Re:what's wrong w/ 8.3? (Score:1)
Who said you were limited to three characters?
---
Re:what's wrong w/ 8.3? (Score:1)
This, but this is the fundamental underlying concept of the 1980s/1990s "GUI" systems. To go beyond it requires a complete rethinking of how a system should work.
Hopefully, somebody somewhere is working on this, but I'm too lazy to go find out.
---
Re:Cross compatibility among heterogenous platform (Score:1)
In 9.0, there was new API to be able to use 255 unichar names (but only on HFS+ volumes).
Efficiency? (Score:1)
A Prime Example (Score:1)
When it came time to install drivers for my wireless network card, I realized I was screwed... because even though the driver disk said "NT Compatable" on it, the long filenames in the driver binaries got mangled in the trip over to FAT16.
So is the problem a company who doesn't do a test install in ALL possible environments, or is it a "Backward compatable" filename system which isnt? YES.
(Grrr......)
Re:You have the power over your own filesystem! (Score:1)
Not only that, but they have a VERSION resource. Got that, Windows people? Every driver, every application can tell you exactly what version it is, right from the desktop. No need to cross-reference the creation date and file size with obscure charts, no need to randomly swap in and out 85 different copies of VX78TY9.DLL until something works.
Re:OK (Score:1)
Yes, this has been fixed. If the application doesn't exist, it will now give you a list of viable options to choose from (i.e., all applications that have nominated themselves as being able to open that type of file).
Filenames (Score:1)
My preference is to keep short names, and run some script over the file to extract the real contents from the file.
For example, you can pull the 'file description' from most Word processor documents. You can put a special comment in a script, and grep for those, eg grep "::~" *.BAT. I've even pulled data out of saved games :).
Long file names are a bugger when the tools do not support them. Try changing to "Program Files\Microsoft Offis\Offis\Winwart", without making an error. MS don't even load DOGKEY for it. NT4 is slightly better in CMD.EXE, if you hack the registry with an undocumented hack.
I prefer to store the file contents in a the 4DOS descriptions. These are visible in text files, so I do not need mount the source diskette.
Some programs depend on the target file being a particular name, these I accomidate with a file of the form $$rename.txt, of lines shortnme long file name.
Storing the file type as an extention is not stupid. What is, is MS's insistance that they be hidden. People run "pickie.mpeg.vbs" because they only see "pickie.mpeg". If they saw the .vbs then they would not likely run it. Also, if you abandon filetype in extentions, then you have very little idea that "erotica" is anything in particular. It could be anything from a rexx script to a mpeg to a vbs.
I use long file names, and use extentions. If I want different words, the name should be of the form "this.is.a.long.file.name.txt".
But I rather pull the data from the file itself, eg 'grep ":~" *.BAT'.
It searches the fat and vfat listings ... (Score:1)
If you run DEL "*~1.*" from a command line that supports extended wildcards, you will delete any file that resolves into a ~1 affix.
It is useful to note that the ~1 system reduces the 8.3 to ten 6.3 systems. Aggh.
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.
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. You can not store Windows in a directory "c:\Microsoft Windows", or Windows is dragged into the "Program Files" directory (I've seen this happen). The DOS boot can't find it. :)
Re:VFAT LFN on Macs and plain DOS (Score:1)
DOS boot disks are not the sort of thing you carry around in your purse...
Re:OK (Score:1)
...some reasons (Score:1)
And actually, there are a ton of idiots who are adopting the new 8.3.3 standard, such as myhotsisternaked.jpg.vbs
Re:OK (Score:1)
So when I click on a ".c" file, will Windows magically know what I want to do with it this time? Edit it? (With which editor?) Compile it? Print it? Mail it to a colleague? Check it in to RCS/CVS/whatever? Check out the latest version? Pass it through the C beautifier? Or any one of a dozen other things that I regularly do with ".c" files.
--
If you don't like the 8.3.... (Score:1)
-Henry
Re:OK (Score:1)
> be embedded in the file, then you Linux users
> would really be crying.
No more so than that the file name itself, or the file size has to be embedded in the file itself.
It's an OS issue. Recording file type as another chunk of data managed by the OS is trivial, and should have been done long ago in Windows, or Unix for that matter.
Having the file type as the end of a filename is fine -- for a quick and dirty hack. But that hack should never have made it into the market (much less the mass consumer market.) Everybody forgets how much like magic it seemed when double-clicking on a data file on a Mac fired up the application that handled it and then opened the file in that app. Anybody working with computers at that time had their jaw drop to the floor when seeing that.
Windows and Unix hack around this by still scanning the extension to the file, which, again, is a fine hack, but makes life extremely difficult for the average consumer should the extension type be changed accidentally (which happens all the time given the tens of millions of users.)
Re:Why do we have /usr and /usr/src? (Score:1)
> Foo\ Source\ -\ Devel\ 1.3.2.tar.gz when I go to
> compile and install the package.
And this concern about typing difficulty has what bearing whatsoever on a modern OS to be delivered to tens of millions of people, who, if expected to do this, would fail miserably at a rate of 1/100 (very optimistic), calling your customer support line at a rate of 10000000/100 = 100,000 calls a day = bankruptcy in a week, or generating vile hatred for your corporation?
And they call it emotion engine... (Score:1)
Re:what's wrong w/ 8.3? (Score:1)
Re:Cross compatibility among heterogenous platform (Score:1)
Why do we have /usr and /usr/src? (Score:2)
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.
Re:Why do we have /usr and /usr/src? (Score:2)
Re:OK (Score:2)
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.
Re:OK (Score:2)
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.
Re:OK (Score:2)
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.
You have the power over your own filesystem! (Score:2)
Re:tab completion and grep in DOS and Windows (Score:2)
So does ksh's file completion....
/home/mark/PERSONAL/
#>ksh
host:#>ls -d ~mark/PER*<tab>
(expands to)
host:#>ls -d
Re:because its an ISO (Score:2)
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.
what you mean "we" kemosabe? (Score:2)
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.
BECA.USE (Score:2)
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.
Re:Speaking personally... (Score:2)
If *I* was using emacs, I'd also need something to help me attain inner calm! ;)
Hmm... (Score:2)
Re:what's wrong w/ 8.3? (Score:2)
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/
Re:what's wrong w/ 8.3? (Score:2)
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/
Re:I agree, but... (Score:2)
Re:Cross compatibility among heterogenous platform (Score:2)
Re:Cross compatibility among heterogenous platform (Score:2)
Don't blame Mac for shortf~1.nam (Score:2)
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 [apple.com].)
That said, there is one area that long names get screwed up -- ISO 9660 CDs. HFS, Joliet, and Rock Ridge [google.com] 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 [versiontracker.com] though.
Re:what's wrong w/ 8.3? (Score:2)
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.
tab completion and grep in DOS and Windows (Score:2)
I'm not on Linux (I miss tab completion the most), so I can't grep for it
If you use Red Hat Cygwin [redhat.com] (GNU software for Windows) or the full version of DJGPP [delorie.com] (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 [pineight.com] are belong to us.
VFAT LFN on Macs and plain DOS (Score:2)
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 [spaceports.com]. Works for LFN-compatible DOS programs such as command.com 9x, edit.com 9x, and all DJGPP programs.
All your hallucinogen [pineight.com] are belong to us.
Re:Hmm... (Score:2)
Actually, I think that this shows part of the reason that people like terse file names; they're easier to type. It's a lot easier to type cd /usr/local/doc than cd /user_files/local_system/documentation. Similarly, if you use the command prompt in Windows it's nice to have short file names to make typing them fast. The one big complaint I have is with people being doctrinaire about it. It's annoying that Windows people use .htm when their system will support the same .html extension that everyone else uses.
well, I don't use *8.3*... (Score:2)
My $.01 (it's not worth that much),
/Brian
Because the Windows/WinNT File Systems still do. (Score:2)
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?
Re:what's wrong w/ 8.3? (Score:2)
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.
Re:what's wrong w/ 8.3? (Score:2)
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.)
Re:You have the power over your own filesystem! (Score:2)
I think the point is... Why doesn't the OEM give it a good name like this in the first place so that I don't have to?
For those who don't know it... on a Mac, in the System folder extensions, control panels, drivers, etc. all have reasonable descriptive filenames -- and often in much less than the thirty odd character limit.
I interpreted the original poster's question as: Why doesn't the world move past 8.3 filenames and start using long (but reasonable) filenames? And I think it is a very good question.
Re:Why do we have /usr and /usr/src? (Score:2)
Is this really true?
I wish I could mod this up.
I've only been using Linux for about two years, and have not explored every last facet nor read every last scrap of documentation and lore.
What, pray tell, do
Enquiring minds want to know.
Re:OK (Score:2)
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.)
8.3 convention (Score:2)
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.
What's wrong with the Tab key? (Score:2)
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.
Re:what's wrong w/ 8.3? (Score:2)
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.
Re:Cross compatibility among heterogenous platform (Score:2)
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.
Re:what's wrong w/ 8.3? (Score:2)
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.
Re:what's wrong w/ 8.3? (Score:2)
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)
what's wrong w/ 8.3? (Score:3)
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
Re:Because the Windows/WinNT File Systems still do (Score:3)
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
Re:Cross compatibility among heterogenous platform (Score:3)
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.
Long Filenames (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.
Microsoft Compiler (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)
I agree, but... (Score:4)
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.
Re:OK (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.
Re:Why do we have /usr and /usr/src? (Score:4)
Re:Why do we have /usr and /usr/src? (Score:4)
/var == Very Active Records
Cross compatibility among heterogenous platforms (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.
Speaking personally... (Score:5)