Slashdot Mirror
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. "
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.
Did you somehow miss the link? It basically said to remove files with a preceding '-' (-filename) you do 'rm -- -filename' or 'rm ./-filename'. And to remove a file with unprintable characters try 'rm file?with?unprintable?characters'.
It's like sex, except I'm having it!
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.
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.
Bogtha Bogtha Bogtha
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.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
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.
WWTTD?
> 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.
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.
The actual maximum length depends on your definition of "maximum", unfortuneately.
.NET was going to free us all from Win32. Guess not.)
:/
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
My opinions are my own, and do not necessarily represent those of my employer.
...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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON