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:spaces bad, special chars bad

[1u3hr]

the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.
the semantic mapping of the extension to filetype, WTF? the implied (don't remember if it was canonical) semantic that no ".3" extension meant the file was a directory

Not true. I used names with no extension for my Wordstar files back in DOS days. Since that's what most of my files were, I made that the simplest. Directories usually had no extension, but you could have if you wanted (some programs did that for their private data).

Winows 9x and above though do enforce rules on extensions; but worst of all, hide some, or all, of them by default. Thus Anna-Kournikova.jpg.exe. The old Mac OS had it right, the filetype flags were not user-created or normally visible, though you could get tools to hack them if you wanted.

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:spaces bad, special chars bad

[vadim_t]

I refer you to the file(1) command:

vadim@gadget ~/src/ac/src/viewer $ file *
Makefile.am: ASCII make commands text
image_list.c: ASCII C program text
image_list.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
images.c: ASCII English text
images.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
mapview.c: ASCII English text
mapview.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
serverconn.c: ASCII C program text
serverconn.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
viewer.c: ASCII English text
viewer.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

As for case sensitivity, it's a seriously thorny issue due to some languages that have lossy upper/lower case conversion.

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.

Press TAB again

[ggeens]

cmd.exe's completion is a bit strange if you're used to bash, but once you get to know it, you can get around quite well.

Example:

• cd c:\pr TAB -> cd "c:\Program Files"
• Another TAB -> cd c:\projects
• "\foo" + TAB -> cd "c:\projects\foo bar"
• "\s" + TAB -> cd "c:\projects\foo bar\src"

Before Windows XP, you had to activate the tab character by changing a registry key. XP has this set by default.

Re:spaces bad, special chars bad

[Xtifr]

> the requirement the ".3" portion be satisfied, i.e., if you didn't give a ".3" extension, it wasn't valid.

Your memory is faulty here--that is not true; not even slightly.

> the semantic mapping of the extension to filetype, WTF?

Long predated MS. Found even in UNIX before MS existed. And still widely used even on UNIX/Linux/BSD. The big flaw that DOS had here (IMO) was making the extension determine whether a file was executable. Having an executable flag is a much better solution. But the approach that DOS took was widely used in other OSes at the time.

> the case insensitive nature of file names

There are plenty of arguments on both sides of this one. I'm more used to/more comfortable with/prefer case-sensitive filenames, but I can't bring myself to claim that one option is better than the other.

I thought VFAT was actually a fairly clever solution to the problem of providing backwards compatibility with the horrors of 8.3, and MS really had no choice but to provide backwards compatibility. I have a lot of complaints with the things MS has done over the years, but I actually kind of admire VFAT.

> defaults to hide extensions

This, on the other hand, is one of the biggest mistakes that MS ever made! Someone should have lost their job over this idiocy!

As a side note, I have to agree with everyone who says that the original article is terrible. The list of characters to avoid for portability is missing several, and the article completely overlooks one of the biggest and most headache-inducing issues--i18n and character encodings. This is one area where UNIX/Linux's ultra-flexibility actually gets it in trouble, since you can have file names with different encodings in the same directory. I actually had a mix of latin1 and utf8 filenames in my home directory for a while, and NOTHING would display them all correctly. And I bet it's even worse if you mix-and-match various CJK encodings. Windows, I'm told, forces everything to utf16, which would not have been my first choice, but at least it's consistent.

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

I'm sorry but...

[Ayanami Rei]

...you suck at scripting.

Typical shell scripting idioms like:

for $each in *glob.pattern* ; do
    command "$each"
    mv "$each" "$(echo \"$each\" | sed -e s/stuff/replace)" ...
done

The only extra quoting necessary is in commands with variable substitution. And (while it may seem confusing), that syntax works even when the filenames have quotes internally. The double quotes identifies the contents to be treated as a single token with interpolation to be performed before passing on to ``command'', which is what you wanted.

Also the $() syntax is your friend. But remember to give it ""s too, you don't want it to expand it AND THEN tokenize it.