Linux/Mac/Windows File Name Friction

lessthan0 writes "In 1995, Microsoft added long file name support to Windows, allowing more descriptive names than the limited 8.3 DOS format. Mac users scoffed, having had long file names for a decade and because Windows still stored a DOS file name in the background. Linux was born with long file name support four years before it showed up in Windows. Today, long file names are well supported by all three operating systems though key differences remain. "

Comments

Long filename horror story

[suso]

Long filenames aren't all they are cracked up to be. I got made fun of once for using one. I can remember it so clearly now, we were in music theory class in high school and we had to use Finale on a Mac (OS 7 at the time) for our composition projects. I named one of my projects something like "Suso's Music Theory assignment number 4 for Mr. Becker 1993-9-24.mus" and saved it. A week later I was on the same Mac and noticed a file that wasn't mine called "Making fun of people who use really long filenames for their music theory assignments.mus". Nobody was admit to doing it but I knew who it was. I was devastated and never felt comfortable again in that class.

Now I'm scarred for life. I should have listened to my parents and gone with 8.3.

Re:Long filename horror story

[mausmalone]

Perhaps that's a bit long of a file name, but it's at least descriptive. I can't tell you how many times I've gotten files titled Agenda 01.doc when they should be more like Tech Committee Agenda 2006-05-01.doc -- it's not excessively long, but with a file name like that I know EXACTLY what's in that file.

Re:Long filename horror story

[OldManAndTheC]

I have a bumper sticker on my car that says:

"I waste my jokes on the accuracy nazis on slashdot."

There's no way that would fit on a bumper sticker.

spaces bad, special chars bad

[yagu]

Why are computer file names and conventions and protocols so messed up? It's bizarre -- and Microsoft has been one of the worst offenders with one of the most powerful positions and opportunities to make it a better filename-naming world.

I had worked in the DOS world long ago, and I'd always been frustrated with not only the restriction of the 8.3 naming convention, but the added imposition of:

1. the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.
2. the semantic mapping of the extension to filetype, WTF?
3. the implied (don't remember if it was canonical) semantic that no ".3" extension meant the file was a directory
4. the case insensitive nature of file names
5. etc. (or should I say, .etc)

Many years later, I had opportunity to consult in the Windows/DOS world after having worked in the Unix world for over a decade -- figured Microsoft had had enough time and money to work out the kinks in what had obviously been an early-technology constraint for the brain dead old DOS naming restrictions. Not. Sigh.

And then the transition was a nightmare, whoever conjured up the VFAT naming format and the "tilde" mapping backwards compatibility to FAT names should have been shot. A golden opportunity lost.

And then everything swings completely the other direction where anything goes. This may curry favor with users, but wreaks havoc on billions of lines of code which all of a sudden choke on what had been simple parsing routines -- fixable, but at great expense. I still think this was a paradigm shift that somehow could have accommodated the user space/community but still allowed some sanity in the machine world.

But layered on, or dovetailed into that quagmire is the Microsoft insistence they "know better than thou"... and the condescending insistence of dragging the ".3" extension nightmare into the new rules for file naming. Would have been okay to "allow" ".3" naming, but to impose the bizarre rules and behaviors Microsoft has? (How many of you have files named picture.jpg.jpg.jpg out there?)

Options to show extension, defaults to hide extensions, and continued reliance and semantics applied to extensions continue to make the filenaming world a landmine field.

And, Microsoft dares to allow mixed case naming, but does case insensitive handling of file names... don't even get me started about some of the bizarre results and buggy behavior I've traced to that. I only wish I'd had a chargeback code for all of the time I've spent fixing and debugging systems that all come back to the file naming. Sigh, again.

All of this isn't to let Unix and Unix style file naming skate. I've had problems, though fewer, there. But, at least it's seemingly (to me) more consistent and predictable, though there has been what I call "Windows" creep in that there have appeared some apps that somehow think managing and imposing "transparently" the extension to "file type" mapping is a good thing (it's not).

(One of the funniest Unix debacles I experienced was debugging a groups application -- they were moving files around and losing all but one each processing cycle... turned out they were remote copying from one Unix that had 14 (or more, can't remember) char limit on file names to an old SunOS system that allowed only 11. The remote copy that moved files from one system to the other for subsequent processing did so without complaint, the receiving side silently truncated the incoming files -- which were identical in name through 11 chars... essentially copying the incoming files over and over again on top of the same file... Sigh and sheesh!)

Re:spaces bad, special chars bad

[Chris Graham]

You have some good points, but I really can't agree with two of your complaints... "the semantic mapping of the extension to filetype, WTF" It seems far better to me than mime-types or magic strings. Mime-types fail due to not being actually encoded on-filesystem, and magic strings require users to use a hex editor to try and identify an alien file type. "the case insensitive nature of file names" Case sensitivity is a big usability issue for people, so burdening the few (the programmers) so that the majority (the users) don't get confused, is a fair trade of IMHO.

File servers!

[WPIDalamar]

Too bad the article didn't mention what happens when you copy long filenames over the network. All kinds of crazy things happen in all kinds of client/server combinations.

Try copying a 40 character file from a windows server to a OSX client. What happens? Well... it depends if you used appletalk or SMB to connect with.

What about OSX server -> a windows client... depends on the version of windows AND OSX of course.

I've had nightmares.

Wanna be safe most of the time:
1) No spaces
2) Under 32 character filenames
3) Alphanumeric, underscore, period, or hyphen ONLY
4) Only a single period allowed.

Re:I RTFA

[rtyall]

I've just heard that all 3 Operating Systems support reading CDRoms? Is this true, can anyone confirm this revelation?

Bah - OS Vendor support of long filenames

[Rauser]

So, your OS supports long filenames, huh? Then why doesn't the vendor use them for all the cryptically named shared libraries, scripts, etc. that clutter up any modern os system directory?

They way I look at it, the day I look at something like "d3d8.dll" or whatever drek is fermenting in \WINDOWS32\ and it is actually named with a descriptive filename, then that OS will truly support long filenames.

Not sure where the Linux crown compares, but OS X is getting better with each revision. Classic Mac OS had this one down (mostly) cold.

Article is incorrect

[joshv]

From the wikipedia entry on NTFS:

"Though the file system supports paths up to ca. 32,000 Unicode characters with each path component (directory or filename) up to 255 characters long, certain names are unusable, since NTFS stores its metadata in regular (albeit hidden and for the most part inaccessible) files; accordingly, user files cannot use these names."

The article incorrectly states "Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: "C:\Documents and Settings\USER\My Documents\"." I will grant that this may have been a limitation in the past, but XP has had NTFS from the start, and NTFS is by far the most common windows FS today.

Re:Article is incorrect

[bmajik]

The actual maximum length depends on your definition of "maximum", unfortuneately.

PATH_MAX is supposed to be defined as the length of any single path segment. NT "the OS", and NTFS "the filesystem", support completely qualified path concatenations that are like 32k or so long.

You can, using CMD.EXE, create a directory 250ish chars long. Then you can go into that directory, and create child dirs with a similar length, and so on, for quite a while.

Now, what happens when you try and access that file you made?

It depends entirely on the appplication.

In XP and earlier, explorer.exe got pretty confused around 4096 chars. When you were viewing a DFS redirected share, explorer got confused even earlier.

in CLR 1.0, if you have relative directory traversal, you can access paths which are longer than 255 chars, but any of the "open by path" routines cap it at 255 chars (including filename!). I filed a bug on this that the CLR guys said "won't fix - we just do what Win32 does". (gosh guys, i thought .NET was going to free us all from Win32. Guess not.)

So, the NT native APIs support enormous paths, NTFS supports them, but depending on which libraries your application uses, you probably can't do much better than 250 chars total - path _and_ filename.

Alot of what makes Microsoft "good" is its commitment to backwards compatibility. And a lot of what makes Microsoft so lousy is it's commitment to backwards compatability :/

Re:c:\progra~1\Micros~1\Powerp~1

[kripkenstein]

Of course - this is a feature, not a bug.

Henderson_Presentation_2005.doc is HENDER~1.doc,
Henderson_Presentation_2006.doc is HENDER~2.doc,
Henderson_Presentation_2006 (unedited).doc is HENDER~3.doc.

Clearly, we are reaping the benefits of a well-thought-out platform here.

Best 8.3 filename mockery

[thatguywhoiam]

The ad that Apple ran, back when Windows 95 launched:

C:ONGRTLNS.W95

Re:Unusual characters in filenames

[Bogtha]

I think the biggest problem I had one day was when I was trying to remove a file in Linux who's first character was -

That is what the -- option is for. It signifies that there will be no further options, so anything following it that starts with '-' will be interpreted as a filename. rm -- -funny-named-file will do the trick.

Re:I RTFA

[kimvette]

Actually all three can be case sensitive.

Linux always is, by default (I don't know if you can make it otherwise without a LOT of hacking).

Windows: it is case "retentive" by default (it remembers cases as typed) but not case sensitive. It (full case sensitivity) can be enabled through a registry hack or two, or by selecting the "enable case sensitivity" option when installing SFU, at the cost of possibly breaking backwards compatibility with many applications.

Mac: OS 9 (and earlier) were case retentive only. OS X is case retentive (no sensitive) by default, however, if you install on a UFS filesystem it will become case sensitive, and just as with Windows, possibly breaking backwards compatibility with many applications.