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

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

[stupidfoo]

Although it was cast as a negative, I always enjoyed being able to use the ~1 (and ~2, ~3, etc) for long names in MSDOS. In my mind Program Files is progra~1 and Microsoft is micros~1.

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

[mrjb]

When you use cmd.exe for a command line interpreter, it makes more sense to type

cd prog*\mic*

Not only will this work, it will also work on other platforms, and it will also keep working when the silly ~1 convention is abandoned.

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

[Delirium Tremens]

Careful with that because if you install -- say -- a software called ProGrabber in c:\, it now becomes Progra~1 and Program Files becomes Progra~2.

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

[cortana]

Ugh, I hate that behaviour. I wish it would use readline's default behaviour. The alternatives ('microsoft' and 'microsaucer') would be listed, and after that the original prompt completed up to 'micro' would appear.

(Readline is the line input library used by Bash and lots of other GNU/Linux software that presents a command-line interface).

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

[LiquidCoooled]

From here:

Use Short File Names

Every time you create a file with a long file name, NTFS creates a second file entry that has a similar 8.3 short file name. A file with an 8.3 short file name has a file name containing 1 to 8 characters and a file name extension containing 1 to 3 characters. The file name and file name extension are separated by a period.

If you have a large number of files (300,000 or more) in a folder, and the files have long file names with the same initial characters, the time required to create the files increases. The increase occurs because NTFS bases the short file name on the first six characters of the long file name. In folders with more than 300,000 files, the short file names start to conflict after NTFS uses all the 8.3 names that are similar to the long file names. Repeated conflicts between a generated short file name and existing short file names cause NTFS to regenerate the short file name from 6 to 8 times.

To reduce the time required to create files, use the fsutil behavior set disable8dot3 command to disable the creation of 8.3 short file names. (You must restart your computer for this setting to take effect.) For more information about disabling 8.3 short file names, see "MS-DOS-Readable File Names on NTFS Volumes" later in this chapter.

If you want NTFS to generate 8.3 names, improve performance by using a naming scheme in which long file names differ at the beginning of the name instead of at the end.

For more information about short file names, see "File Names in Windows XP Professional" later in this chapter.

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!)

Unusual characters in filenames

[Rik Sweeney]

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 -

rm and mv kept complaining that the character after the switch wasn't valid and eventually I had to navigate to the file in X and delete its icon which did the trick.

Not a particularly exciting story, but an interesting one none the less.

Re:Unusual characters in filenames

[91degrees]

That is a directory with no files but several other directories in it...

Any way to turn off Joliet support in Windows XP?

[esnible]

I've got a CD-ROM that is unreadable under Windows XP because a Mac user put the files in a directory containing a '>' character.

If I can turn off Joliet comprehension I'll have access to the files in their original ISO9660 8.3 glory.

It's unfortunate that Microsoft's Joliet driver doesn't realize it's presenting names the OS can't tolerate. Otherwise it could replace the forbidden characters with % escapes before returning them to the OS. Or, alternately, handing the ISO9660 name to the OS if the Joliet name was forbidden by Windows' rules.

What about standards?

[3gm]

Why not simply follow the POSIX standard*? You can avoid a lot of hassles that way. Isn't that why we have standards?? I know, it doesn't resolve the conflict with Windows case "insensitivity", but ... it does provide interoperability between POSIX-compliant OSes. * upper/lower case alphabetic characters, numeric digits, underscore, dash, and period.

Re:Tagging

[El Tonerino]

Have you looked at http://www.chipx86.com/wiki/Leaftag

Re:Long filename horror story

[zsau]

Even though others apparently claim you're joking, I personally am all for gratuitous words in file names. Some times I achieve this by gratitously deep folder heirarchies, but usually I just randomly add keywords to files. I mostly use a GUI, so it doesn't stress me out too much, but makes it much easier to find them two years later.

(I also like my music files to accurately contain the name of the track, so a song like "Where is everybody?" becomes "(maybe the artists name, album etc. -) 03 - Where is everybody?.ogg". Worse, if it's "Starfuckers Inc.", it becomes "06 - Starfuckers, Inc..ogg". It quite annoys me when I try to copy the files to my music player, which has a FAT-based filesystem.)

Re:NTFS WTF?

[Quantam]

Yes and no. That was a limitation of Windows 9x (a holdover from DOS and Unix), and still exists in the ANSI versions of the NT APIs. However, the native NT Unicode APIs support 32k characters for the path. I don't know if there's a 255 char limit on individual names for NT, off the top of my head. Though it's possible that the number of programs still using the ANSI APIs (since the Unicode version only works on NT, but the ANSI version works on 9x as well) may impose an artificial limit of 255 char paths on your file system.

Windows... everybody knows.

[ThePhilips]

Windows here suck the most. NTFS is good, but all the backward compatibility cruft just drags the FS down.

Once under Windows, I have spent about half an hour with Explorer refusing to copy one one. Explorer was insisting that "File No Found". Text file was there and perfectly editable by notepad. I needed about 30 minutes to observe that Explorer was giving error on only on file of whole directory and that file have had the longest name. ZOMG!!! They still have cap 255 bytes on path(!) length!!!

Welcome to 3rd millenum, Microsoft! Where do you want to go today?!?

End-Of-Sarcasm.

Realistically, I never had a single problem with Mac or Linux when handling file names. But when you get to Windows, you start getting the annoying messages from explorer "invalid character" with attached long list of characters they do not allow to use. All the time. And I'm not talking about bunch of non-Unicode applications (for example Adobe Acrobat Reader) which cannot open file with name containing international characters. Could it be any dumber?

Why name stfuff?

[NotInTheBox]

I want documents not files. Sometimes multiple files make up one document (webpage + stylesheet + media), sometimes there are multiple documents in one file (zip).

When will anyone come up with a persistant storage system which allows me to make random tags to documents and groups of documents. Drop the folders and give me 'search queries' on content and tags. Automatically save all data and don't bother me with giving it a name... When it's important I will give it the proper tags until then just remember it for me.

Do I have to name the paper before printing?

NTFS Streams

[Meneguzzi]

I know this might sound a bit offtopic, but since the post mentioned windows filesystems, I felt it might be a good place to throw this question...
Not many people know or have even used this, but NTFS has support for multiple streams of data in a single file, which is something that borrows concepts from object-oriented filesystems. This is scarcely, if at all, included in the regular windows documentation (it is documented in the MS knowledge base http://support.microsoft.com/kb/105763/). I thought it to be a nice idea for, say, media files, to store the audio in one stream the the video in another, or adding subtitles or metainformation in different streams in a very standard way. But for some reason nobody used that, not even Microsoft who designed the feature.
Does anybody have a clue as to why this has not been used?

Windows XP still uses 8.3 format

[Yuioup]

1. Run regedit.

2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Eventlog\Application\

3. Click on every folder underneath that one. Look at the eventmessagefile key.

Have you noticed that all of them have an 8.3 format?

It's a bug I came across in Windows. I tried to register a file for use in the Windows Event Log. It didn't have an 8.3 format. Windows barfed all over it.

Y

can we finally hide the FS?

[fikx]

Personally I like the Linux (Unix) method. Nothing wasted. But, have we reached the point yet were we can abstract the filesystem away from users? It's nice for an admin to be able to poke around and fix problems, but can we come up with one set of rules on filenames (Linux please!) and then have the OS read the FS and put a pretty picture of those rules in front of the common user? One of my biggest wonders in computers has been the fact that the underlying FS determines what file names and such I have to juggle. That's kinda annoying. Why haven't we come up with an API to abstract this yet?

Re:Long filename horror story

[Anonymous Coward]

Sysadmin horror story: somebody using a Mac to mount a UNIX NFS share managed to create a filename with a slash in it on the UNIX box.