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!
Those filenames are longer than the 31 character limit on Mac OS systems. You're lying.
MacOS was limited to 31 character names, so you're misremembering things.
Whenever I hear the word 'Innovation', I reach for my pistol.
err... no.
linux et,al. == case sensitive
windows == case insensitive
OSX == case preserving
Try to keep up.
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.
As a quick tip, "rm -- filename" would have worked; it makes rm not parse the filename in any way whatsoever.
Trust the Computer. The Computer is your friend.
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
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).
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
File names aside, is there a good way to "tag" files (generic metadata) on Windows or Linux?
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.
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).
They have a whole block on "Avoid using these characaters for maximum portability".
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.
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
Not so. It goes to the first created file. So if you create microsauer, then microsoft, but delete microsauer later, microsoft will stay as Micros~2
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").
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
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.
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.
Dos 1.0 had no directories, and arbitrarily used / for options (remember DIR /P ?). When 2.0 came out, to preserve backwards compatibility they kept / for options, so decided on \ as the directory separator. Modern dos/windows can handle / for directories fine, but they need to still support \ for - you guessed it - backwards compatibility.
I am trolling
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.
Or more simply put: Once a folder is created as PROGRA~1, it stays PROGRA~1. It doesn't cycle.
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.
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.)
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.
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.
If extensions aren't part of filenames, then you have the same problem as hidden extensions: You can have a file with the name "Hello" which is an executable but tricks users by using a jpg icon for the application.
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.
The Joliet filename length limit is somewhat below 120 characters because the record it is stored in cannot exceed 255 bytes. The record includes the starting extent and the file size in big and little endian format, and the name is stored in Unicode.
...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