Linux/Mac/Windows File Name Friction 638
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. "
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.
Re:Ouch (Score:4, Informative)
Re:Long filename horror story (Score:0, Informative)
Re:Long filename horror story (Score:3, Informative)
Re:I RTFA (Score:2, Informative)
linux et,al. == case sensitive
windows == case insensitive
OSX == case preserving
Try to keep up.
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.
Re:Unusual characters in filenames (Score:2, Informative)
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.
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 volume (i.e. the one the OS is installed on).
Re:spaces bad, special chars bad (Score:5, Informative)
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:Unusual characters in filenames (Score:1, Informative)
IIRC the "--" is not an command specific feature, but is a feature of the bash shell (and probably others).
No, it is a feature of getopt(3).
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: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.
Re:c:\progra~1\Micros~1\Powerp~1 (Score:2, Informative)
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.
No, on Linux they go in "/usr/local/bin" and "/usr/local/etc" and one or more users' "~" only, because "/bin" and "/usr/bin" are reserved for bits of the OS itself (equivalent to "C:\Windows" and "/System").
Re:Where's the !? (Score:3, Informative)
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.
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 meaning can be removed by prefacing it with a backslash, i.e. "!" -> "\!" -- Linux and the filesystem and all the relevant system calls still use the "!" character itself in the name of the file.
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.
Re:Long filename horror story (Score:3, Informative)
Many shells now support the use of the "Tab" key to expand a filename (and list filenames that match what you have typed in so far). Also, if your music player is an iPod then you can format it with HPFS and lose that FAT restrictions - though, I believe the iPod actually just mangles the filename and uses the ID tags.
Re:Any way to turn off Joliet support in Windows X (Score:2, Informative)
Re:Does someone have a problem or two? (Score:3, Informative)
Is this anything other than an attempt to dis Windows for no other reason than 'Because'?
I think it is a valid issue. There are some files in a CVS module I simply cannot use on Windows because the filesystem chokes when CVS tries to write them in Windows and the rest of the CVS commit is aborted. It is a huge pain in the ass, even though these files do not contain any capital letters. This happens with ever CVS client on Windows, even Cygwin. MS needs to get off their butts and fix this crap once and for all.
Re:c:\progra~1\Micros~1\Powerp~1 (Score:3, Informative)
The number is incremented in the order the folders are created, not alphabetically.
Though, I recall on at least one occasion some sort of massive registry failure, requiring that I reinstall Windows 95. From then on, my Program Files folder was known as PROGRA~2.
Re:Long filename horror story (Score:3, Informative)
Nope. File metadata in extension. File description in name. Keep 'em separate!
TOTPUSSY.YOU or TOTALPUS.YOU
And now you can burn it to an ISO 9660 CD-R and be sure of getting the right filename, every time, even on ancient versions of SunOS/Solaris that refused to read Joliet! (Time heals all wounds. Slashdot threads on cross-platform file naming conventions reopen them.)
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.
Re:spaces bad, special chars bad (Score:3, Informative)
Mac OS had a separate file type, and file creator, code. So apps could share filetypes, but have distinct creators. But egomaniacal programmers often made their apps change the codes. That's when you needed things like FileTyper.
Re:spaces bad, special chars bad (Score:1, Informative)
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
Re:Long filename horror story (Score:1, Informative)
Re:Press TAB again (Score:3, Informative)
Forget hacking the Registry, TweakUI can do this. It's an essential tool for Windows that would cause too much damage by lusers so they don't ship it out-the-box. Lot's of useful hacks.
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.
Re:File servers! (Score:3, Informative)
Example:
If I want to point someone on the corporate network to a huge file which resides on a network drive we can both access, I can just send a mail with this text: Both Outlook and Thunderbird will create a link to the file when showing this mail.
However, this will not work in Thunderbird nor Outlook: This will not work in Thunderbird nor Outlook: This will work in Thunderbird, but not Outlook: Disclaimer: My Outlook testing was done in Outlook 2000 and 2002/XP. Outlook 2003 may be different.
Re:I'm sorry but... (Score:4, Informative)