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

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

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 :/