Slashdot Log In
Linux/Mac/Windows File Name Friction
Posted by
Hemos
on Mon Jul 10, 2006 08:46 AM
from the like-doing-it-with-sandpaper dept.
from the like-doing-it-with-sandpaper dept.
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. "
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Long filename horror story (Score:5, Funny)
Now I'm scarred for life. I should have listened to my parents and gone with 8.3.
Re:Long filename horror story (Score:3, Informative)
Re:Long filename horror story (Score:5, Funny)
I have a bumper sticker on my car that says:
"I waste my jokes on the accuracy nazis on slashdot."
Parent
Re:Long filename horror story (Score:5, Funny)
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.
Parent
Re:Long filename horror story (Score:4, Informative)
HFS+, introduced in Mac OS 8.1, allows filenames of up to 255 characters, but Classic Mac OS never, for all intents and purposes, supported it.
If you're going to try to correct people, you should probably make sure you're correct yourself so you don't end up looking like an ass.
Parent
Re:Long filename horror story (Score:3, Interesting)
(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 ever
Re:Long filename horror story (Score:5, Insightful)
Parent
I'm sorry but... (Score:5, Informative)
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.
Parent
Re:I'm sorry but... (Score:4, Informative)
Parent
c:\progra~1\Micros~1\Powerp~1 (Score:3, Interesting)
Re:c:\progra~1\Micros~1\Powerp~1 (Score:3, Interesting)
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 (Score:5, Insightful)
Parent
Re:c:\progra~1\Micros~1\Powerp~1 (Score:3, Interesting)
(Readline is the line input library used by Bash and lots of other GNU/Linux software that presents a command-line interface).
Press TAB again (Score:5, Informative)
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:
Before Windows XP, you had to activate the tab character by changing a registry key. XP has this set by default.
Parent
Re:c:\progra~1\Micros~1\Powerp~1 (Score:3, Interesting)
Re:c:\progra~1\Micros~1\Powerp~1 (Score:5, Funny)
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.
Parent
I RTFA (Score:5, Insightful)
For those of you who haven't read it, here it is: Windows, Linux and Mac OS X all support long file names, albeit differently. Linux is case sensitive, the others are not.
Tada! Two sentances. I imagine, were I a perl coder, I could have done it in half of one, but there you go.
Re:I RTFA (Score:5, Funny)
Parent
Re:I RTFA (Score:5, Funny)
Parent
Re:I RTFA (Score:5, Informative)
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.
Parent
Re:I RTFA (Score:3, Informative)
OS X is not case sensitive by default. It is case preserving, meaning that "Foo.txt" will still be "Foo.txt" when you move it or whatever (unlike in Windows, where it could turn into "FOO.TXT", but both names are still exactly the same file. Beware of this when copying files from a Linux (or otherwise case sensitive) filesystem to a Mac!
Now, OS X does have the option to use case sensitive HFS+ (or UFS, for that matter), but last I heard either is likely to cause problems if you try to use it as the root vo
spaces bad, special chars bad (Score:5, Interesting)
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:
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 (Score:5, Insightful)
Parent
Re:spaces bad, special chars bad (Score:5, Informative)
Parent
Re:spaces bad, special chars bad (Score:5, Insightful)
Seems, yes. Is? No way in hell.
The problem is that extensions are part of the filename, i.e. they are arbitrary. Mapping arbitrary data to meta information is stupid at best, dangerous usually and in combination with hidden extensions and automatic execution it is a blatant disregard of even the most basic security procedures.
aka "lookhereiamcertainlynotavirus.jpg.exe"
Parent
Re:spaces bad, special chars bad (Score:5, Informative)
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.
Parent
Re:spaces bad, special chars bad (Score:5, Informative)
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.
Parent
File servers! (Score:5, Informative)
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.
Any way to turn off Joliet support in Windows XP? (Score:5, Interesting)
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.
Re:Any way to turn off Joliet support in Windows X (Score:3, Insightful)
Bah - OS Vendor support of long filenames (Score:5, Insightful)
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.
What about standards? (Score:4, Interesting)
Article is incorrect (Score:5, Insightful)
"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 (Score:5, Informative)
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
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
Parent
Amiga (Score:3, Insightful)
Dan East
Best 8.3 filename mockery (Score:5, Funny)
C:ONGRTLNS.W95
Where's the !? (Score:3, Informative)
But, where's the exclamation mark? TONS of Windows people (including me) use exclamation points as the first character to put files/directories to the top of the list. Linux constantly chokes on these characters. But, no mention of it at all in this article.
Re:Where's the !? (Score:3, Informative)
Re:Where's the !? (Score:3, Informative)
No it doesn't. Linux (like most UNIXes) have no problem with exclamation marks. In fact, the only characters specifically disallowed are NUL (for C compatability) and
Your shell however, assigns a special meaning to the "!" character, and that special m
rsync (Score:4, Insightful)
I just hit the file name issue trying to sync some stuff between unix / Windows XP using rsync.
The case insensitivity was annoying and the limited char set on XP was no good.
Again, you would think they would have fixed this on XP.
colon in Mac OS X file names (Score:4, Insightful)
In Terminal.app, you can create file names with colon, but such character is mapped to a forward slash when seen in Finder. On the other hand, you can use forward slash in Finder, and it is mapped to a colon in the command line.
Historically, Mac OSes use colon to separate folder names in a path.
There is a subtle restriction in HFS+. All files in HFS+ have their names in normalized unicode [unicode.org], and in order to normalize in the first place, file names must be in valid UTF-8 encoding. You cannot use random character string for file names.
There is no such restriction for UFS on Mac OS X. I think UFS supports roughly the same characters as in BSD and Linux and any other Unices. If you're transferring files from Linux with names in a legacy encoding, you can create a UFS disk image and convert file names to UTF-8 before copying them to HFS+.
Re:Ouch (Score:4, Informative)
Parent
Re:Unusual characters in filenames (Score:5, Informative)
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.
Parent
Re:Unusual characters in filenames (Score:5, Insightful)
rm
Parent
Re:Unusual characters in filenames (Score:4, Funny)
My favorite shell-expansion moment: when I was a new Unix user long, long ago (freshly coming over from VMS), I wanted to remove one funny-named file in a directory. I discovered that rm had this cool switch "-i" that would prompt for removal on each file. Great! I'd just say "yes" to the file named *, or whatever I'd accidentally created. So, being a VMS user (and thus used to switches that went anywhere on the command line), I typed this:
$ rm * -i
Parent
Re:Unusual characters in filenames (Score:3, Funny)
rm /home/someuser/-file
Or even
rm ./-file.
Re:Tagging (Score:3, Informative)
On NTFS, you can use ADS (Alternate Data Streams) to store metadata about a file, though I don't know of any software that can read such data in a consistant manner - Not to mention, just about every malware scanner out there will flag such files as suspicious.
On Linux, it very much depends on the FS you choose, though again, support for file metadata remains about as standardized as snowflakes.
Re:Who gives a shit that linux supports long names (Score:3, Informative)
No, they go in "C:\Program Files" and the Registry and one or more users' "C:\Documents and Settings\%USERNAME%\Application Data" folder.
No, they go in "/Applications" and "/Library" and one or more users' "~/Library". Also, by the way, OS X does have /bin and /usr/bin and all the other UNIX standard folders; they're just hidden from the finder.
Re:NTFS WTF? (Score:3, Interesting)
Re:If this had been fark... (Score:4, Funny)
Ah the magic words for +5
Parent