(rant)My big annoyance with all that is computers is not using 4+n character file extensions. I'm tired of EVERYTHING (almost) using a stupid 3 letter file extension. Is it so hard to call a file with an extension like 3dmodel, pngimage, or preferences?

Sure, everyone might want to use an extension like 3dmodel, but thats why you'd pesonalize the extension. I'd make mine dra_3dmodel. It tells you what the file is and the format. You wouldn't confuse it with another 3d file format whose extension was 3dmodel_ea_games.(/rant)

Is anyone with me here? Aren't you tired of tiny weenie file extensions?

The only reason for file extensions is to be backwards compatible with backwards OS's hence people use 3 to be maximally backwards compatible.

The most restrictive file system still in common use is probably ISO 9660. At level one file names are restricted to 8.3 form. Most system now support at least level 2 which allows names upto 31 characters long (including the 'dot' and extension). While this does allow extensions longer than 3 characters, you wouldn't want too long an extension as it then reduces the length of the name you can use.

I guess my issue is, I don't care about being backwards compatible with most systems. The three that I use (win, lin, mac) can all handle longer extensions.

I just get a tad 'bonko' when I start a new project and the custom files, such as configs and such, all have 3 letter extensions. Its really only a trivial amout of typing extra.

A related rant would be not using spaces in file names. I'm open to all flames about this, but I refuse to keep pretending I'm using an OS from 10 years ago which choked on a space in a file name. I'd much prefer -

Vacation Feb 03 001.photoVacation Feb 03 002.photo

to

vacf03001.img

If you drop in underscores where the spaces are in the first names, at least its visually readable still.

I guess this is more a commentary on how things are done now, based on how things used to be done, whether they need to or not.

I would like extensions to be able to be longer, but I don't like the whole "dra_3dmodel" and "3dmodel_ea_games" idea. Imagine writing the program that's supposed to be able to read all that. I'd much rather prefer one "3dm" format for all 3D models that was compatible with all other types so you wouldn't need 8 different programs to handle a project's worth of 3D development. Exploding the number of extensions would make compatibility and conversion a nightmare.

There are no systems still in use (by anyone that counts) that can't handle >3 char "extensions". Heck, even the Commodore 64 used 16 character file names.People still writing stuff to DOS limitations should be shot along with the same group that forced the DOS limitations on us for well over a decade after they were obsolete (that would be Microsoft )

Though Windows XP is STILL incredibly broken in many ways concerning the file system (NTFS). E.g. you can not make a file that ends with a period. You can't make a file that is named COM1.txt It thinks you are talking to a serial port despite the .txt extension. Even a full path name "C:\temp\com2.this_is_not_a_com_port" won't work.

On modern OS's (of which I do not include WinXP, given it is still chained to these ridiculous DOS limitations) there isn't even a concrete concept of an "extension" the name is the name and if you end it with dot-whatever so be it. The ending of the file name may still be used to guess how to interpret the data within though.

And the reverse - you can't actually make a file that has just an extension, like .project That always annoys me when I have to go tinkering with Eclipse project files.

Um, yes you can. I have several on my system right now. In fact you must know that since Eclipse DOES save files with that name. Are we talking about the same thing? maybe you are talking about a limitation of windows explorer or the command line shell. I'm talking about the filesystem namespace, which is totally hosed.

I kinda like them. It lets the user see what type a file is directly from a dir or a ls.

It would also suck to download something called "license.txt" that has it's icon set to the "text document icon", but really is a nasty trojan executable.

This is my point. There is no standard for showing file types to end users. The extension is the best thing that has widespread use so far. That's also why it is criminal for Microsoft to disable showing the extension for so-called "known file types"

Icons could work, but they don't work reliably to show file type, at least on windows where apps routinely hi-jack extensions. Not to mention the fact that most trojans do infact include an icon resource to make the file look like a harmless image or text document as you wrote above.

Malohkan - Weston was right about what I was proposing. I think the file name should be more descriptive of the content. I definately don't advocate creating new file types, just for the sake of it.

I suppose its hard to seperate OS issues from file system issues.

Windows - Hides extensions and system files in its GUI, unless you alter the behavior. The filesystem (Fat32, NTFS) appears to choke on names greater than 8.3 and does something to get around this. IIRC, using win98 you could drop into the command line and do a dir. The longer file names would show up as myfile~1.txt and other variants all containing ~# before an extension.

Linux - Seems to hide all files and dirs starting with a . They also have this weirdness about knowing what you want to execute, unless you alter the shell?, as you have to preface your executable with ./programname to run it. Of course you can see the hidden ones using a switch with ls.

Mac - Doesn't allow me to name files with the same name when using a different case. Seems a little weird, since Fred.text and fred.text are different in Unix land. The GUI presents programs as a single file, but there is some sort of 'packaging' going on. TextPad for example is really a directory name, with other stuff in it. Nested inside the directory is the actual binary. I'm sure there is a name for it, but I'm too much the newbie to the OS to know right now.

BeOS - Had a journaled filesystem capable of handling 64 Terabytes IIRC. How cool was that?

Amiga - Had a 'pairing' scheme, where anything you wanted to run from the GUI (pre OS2.x) had to have an associated icon file. If you had myprogram, then you needed to have myprogram.icon. The icon files contained image data but later contained meta data as well. You could run the executable from the command line, whether it was a GUI app or not.

Because linux is outdated and mostly doesn't have the concept of a hidden file, and instead uses the common unix convention adopted aeons ago of "to hide a file, prepend it's name with "."".

Quote

They also have this weirdness about knowing what you want to execute, unless you alter the shell?, as you have to preface your executable with ./programname to run it. Of course you can see the hidden ones using a switch with ls.

It's badly explained to most linux users, but it's a security feature. Since linux has practically no builtin commands, they're afraid that someone could put a file "ls" into a directory, which is actually an "rm -R /" and you would run it by accident whne you typed "ls".

There are other, more humane, ways of dealing with this threat, but this is a pretty simple and highly effective one: . is never in your path.

Mac - Doesn't allow me to name files with the same name when using a different case.

Hmph. The linux kernel is still broken (has bene for 5+ years) with mounts that decapitalize all capitalized filenames. It's a data-loss bug that linux developers dont think is worth fixing.

Mac also does some nice-but-unfuriating things - like allowing almost any character in a filename, that either corrupts the files or crashes other OS's when you're transferring files from OS to OS, because most OS's can't cope with things like plain * and ? in a filename!

Windows - Hides extensions and system files in its GUI, unless you alter the behavior. The filesystem (Fat32, NTFS) appears to choke on names greater than 8.3 and does something to get around this.

This hasn't been an issue for years.

Quote

IIRC, using win98 you could drop into the command line and do a dir. The longer file names would show up as myfile~1.txt and other variants all containing ~# before an extension.

That was a backward compatibility hack for old software that didn't understand that filenames could now have reasonable names.

Quote

Linux - Seems to hide all files and dirs starting with a . They also have this weirdness about knowing what you want to execute, unless you alter the shell?, as you have to preface your executable with ./programname to run it. Of course you can see the hidden ones using a switch with ls.

Blah^3 has explained the security issue around not having the current directory in the path. The "hide stuff starting with dot" is at least a standard unix convention. It is similar to the file extension issue in that a naming convention is used for more than just the name. Rather that needing to learn some new obscure way to make files hidden, this 'easy' workaround is employed.

Quote

Mac - Doesn't allow me to name files with the same name when using a different case. Seems a little weird, since Fred.text and fred.text are different in Unix land. The GUI presents programs as a single file, but there is some sort of 'packaging' going on. TextPad for example is really a directory name, with other stuff in it. Nested inside the directory is the actual binary. I'm sure there is a name for it, but I'm too much the newbie to the OS to know right now.

Mac OS like Windows and AmigaOS uses a case preseerving but case-insensitive file system. I prefer it to case sensitive file systems, since I think it is more confusing than helpful to have filenames that differ only by case. This can cause problems though.

The 'package' concept is where the Mac is brilliantly superior to other OS's. It is only the Mac GUI - the Finder - that by convention doesn't recurse into package contents unless explicitly told to (context menu 'Show package contents'). The package concept makes application installation a trivial drag and drop application, and complex documents containing many files can be treated as a single entity. In the old days there was a special attribute set on the folder to say "this is a package", now OS X can just recognize a specific directory layout as being a 'package', so once again they use a simple technique that doesn't require any new interface to manipulate special bits... simply recognizing the layout makes packages easier to deal with most of the time.

Quote

BeOS - Had a journaled filesystem capable of handling 64 Terabytes IIRC. How cool was that?

It's cool, but Windows and Mac also use journaled filesystems by default, and most modern Linux systems are the same. I'm not sure where the limits are in terms of partition size.

Quote

Amiga - Had a 'pairing' scheme, where anything you wanted to run from the GUI (pre OS2.x) had to have an associated icon file. If you had myprogram, then you needed to have myprogram.icon. The icon files contained image data but later contained meta data as well. You could run the executable from the command line, whether it was a GUI app or not.

Old windows 3.1 stuff used a similar concept that is still supported today for legacy stuff. I think it was .pif files.

Blah^3 wrote that the Mac can have files with almost any character in the name. The Amiga also had this ability. The backwards DOS/Windows stuff kept it away from most users still to this day. It's been 20 years and we still have the artificial limitation on what characters are allowed in filenames in the worlds most popular OS. Sad. I'm not sure if Linux can handle anything like it either.

There is no good reason to restrict what characters are allowed in a filename. Simple escaping rules can allow path separator characters and the like to not hold special meaning. If this were implemented from scratch today, perhaps the rules for escaping characters in URLs would be the way to go.

Don't get me started on the arcane and ludicrous concept of "drive letters" that Windos is still forcing on users decades after better systems were introduced by Atari, Amiga, and Mac, not to mention the single rooted filesystem of the unix world. Microsoft is directly responsible for keeping general computing in the dark ages. All because they want to be backwards compatible with DOS - the boat anchor that brings down the whole OS.

I much prefer the way Mac moves forward and knows when it is time to simply not be backward compatible with something that puts such severe limits on progress.

Yes, but you can set the file preferences to show the extension always, that's what I do.

Well of course, everyone with half a clue knows enough to turn that back on first thing.. the problem is that for the people for which it matters the most, those without a clue, it never happens. Most users haven't got a clue how to do that and they don't even know that they should do it. Yet another way that MS screws the consumer one tiny bit at a time.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org