Mac can do it, why can’t Windows?
- 6
- Add a Comment
As many of you know, Macs can name a file anything. And I mean anything.
You can name files using !, /, ?, “, etc…
On windows, you cannot use these symbols, or certain words. For example, you cannot make a folder and name it “con” (no quotes). You can do this on a Mac.
I know it has to do with the structure upon which the Operating Systems are based, but in the next iteration of Windows, I would like to see them do something about this. I am tired of me having a file on my mac named something, transfer it to my Time Capsule, and not be able to copy it onto my Windows machine. It can read it just fine. It knows the file type, and all the details about the file. It cannot be run or copied though. I cannot even rename it to something Windows would like better. I have to get on my mac, change it there, and refresh in Windows. It is annoying and pointless.
I don’t know exactly why Windows can’t do this, I don’t know much about the hard code of both OS’s, but I do know that there should be some way around this.
I’m not expecting anyone to have a solution, I don’t think there is one. I just think that Windows should find a fix to this. If anyone has had problems with this, please leave a comment letting everyone know how many people it bothers!

6 Comments
Aryeh Goretsky
July 30th, 2008
at 9:42pm
Hello,
On my computer running Microsoft Windows Vista, I was able to create a directory named “!” (exclamation point). Perhaps you were thinking of the “|” (pipe) character?
The reason you cannot create file (or directories) with characters such as “/”, “?” and “*” is because they are reserved as various types of operators by the file system.
The / character is used to refer to the root of a volume, for example, if I were in a directory named C:\TEMP\FOO\ and typed “CHDIR /”, I would then be changed to the root directory of drive C:.
The ? character is wildcard character used as a placeholder for a single character. For example, if I was in if I were in a directory named C:\TEMP\FOO\ containing files named A, AB and ABC, and typed “DIR A?”, I would see the files A and AB, because they matched the argument given to the DIR command to show all files begining with the letter A or beginning with the letter A and having one more character (but not two) in the name of the file.
The “*” character is a wildcard, too, however , instead of matching just single character, the asterisk denotes zero or more characters. Using the above example, if I typed “DIR A*”, I would see the files A and AB and ABC because they all had zero or more characters following them.
Names such as AUX, COM1, CON, LPT1, NUL, PRN and so forth are reserved MS-DOS device names used to specify a device attached the computer, such as a modem or printer. Having these devices accessible via a filename made it easier to read and write data to them. Although there are not too many people who do such things these days, it is convenient to do things like type “DIR C:\TEMP\FOO\A* > LPT1 and get a directory listing of a files beginning with the letter A in the directory DIR C:\TEMP\FOO\ sent to the printer.
My suggestion would be that if you are working with different operating systems such as Mac OS X, Microsoft Windows and Linux to avoid using characters or words which might be reserved in any of them to remain as flexible as possible when moving files.
Regards,
Aryeh Goretsky
Kittyburgers
July 30th, 2008
at 11:09pm
Sure, I agree with you 100%. It seems rather odd that in this day and age that one should have to be concerned about file naming conventions. This can’t be progress. There surely must be a way for Windows to be able to get around this problem. It must be possible somehow, at least one would think so.
code monkey
July 31st, 2008
at 5:45am
You probably wont get the following characters anytime soon. They have special meanings in the windows command line, which the windows GUI is heavily dependent on. Though their are ways that ambiguity could be resolved, it would be mean a couple things. First any program written in the last thirty/forty years could become unstable if they didnt plan ahead, second they would have to edit a lot of stuff to accommodate this, they would have to change their backward compatibility if at all possible policy.
: ” / \ | ? *
The soonest that might be expected is windows 7 and that would only be if they decide to finally do what apple did with OSX and scrap their old code base and start with a modern clean core, hopefully clean out their APIs and services too. Given the estimated release of 2010 such a drastic overhaul is unlikely. It will probably be an incremental improvement on Vista.
Marcus Hamaker
July 31st, 2008
at 5:46am
It’s annoying that all OSs don’t follow the same rules. I find it more annoying that all OSs don’t use the same file system. NTFS on a Mac or Linux just isn’t easy. But the file naming really doesn’t bother me. I know what the Windows rules are and when on my Mac I just make sure to follow the same rules. Then there is no way that an error can occur.
Bryan Price
July 31st, 2008
at 6:46am
Backwards compatibility is a bitch. Without Microsoft developing a whole new file system and completely dropping backwards compatibility or at least throwing in some kind of shiv to defangify the problems of letting everything through when you are accessing an old volume, I don’t see it happening in the near or even middling future.
If current Mac OS handles :’s in filenames, then Apple has definitely down that. Pre 10.x(9.x? I can’t remember now) used :’s as directory separators. I wouldn’t know, I don’t run Mac.
And yes, there are a handful of file names that are forbidden. con, prn, com1 through com9 (it used to be com5 and up was available under MS-DOS), aux lpt1 through lpt9 (MS-DOS limit was LPT3) and nul (notice the missing l). You used to be able to get a directory under MS-DOS of what was forbidden. Create the \dev directory and do a directory for all files.
Creating a file starting with hex E0 was problematic because that’s one way that MS-DOS showed that the file was deleted. That’s also why you needed to supply the first letter to recovered deleted files.
The last makes for some nice command line hacking. To see if something exists as a subdirectory, you just put a test in:
if exist something\nul then echo Something exists as a directory
Yes, I know Mac has better conditional statements that make this a kludge. But then, Windows and MS-DOS have had a command line much longer than Mac OS. Microsoft decided that they didn’t need or want to clone Unix sh/bash/ksh/csh/… Again, probably for backward compatibility. I have ancient MS-DOS 3.3 .bat files that still work quite well under XP/Vista/Server 2008.
All in all, I don’t think that Windows has a bad thing. Using wildcards in your filenames may seem dandy with your GUI until you need to manipulate those files from the command line. Then you start to either use wildcards creatively or start quoting everything. The handful of 3 and 4 character filenames I can’t use, not a problem. If you have to use them, use an extension.
! is a valid Windows filename. ^ is a special case, &, ‘ and ” need quoting.
The only characters that you really can’t use are /, \, *, ?, ” and :
I just don’t see it as a huge problem.
Exothermic Reaction
August 1st, 2008
at 3:52pm
The problem comes from the backwards compatibility with the old DOS way of handling filenames. Unfortunately the people who developed DOS did not fully understand the unix shell functionality they were attempting to duplicate and got parts of the filename processing in the wrong layers of the operating system.
On *nix operating systems the wildcard characters * ? are expanded by the shell before being passed to the program specified by the command. DOS choose to just pass the command line as-is and have the application decide if it needed to do wildcard expansion or not.
The reserved device names are a problem because DOS was designed to not require you to specify the /dev/ to single out that your were specifying the name of a device. There was a config.sys setting that could be set to require the /dev/, but was never used. If you really want to give a windows user a head-ache, there are a couple of old DOS 1.0 file manipulation functions that will allow you to put these special characters in a filename, but then they are the only functions that can access and get rid of such a named file once it is created.
On *nix operating systems / and : are about the only restricted characters due to having special meanings relating to directories and remote file system protocols. Every other character can be escaped or quoted when specified on a command line.
Exo