As long as your file names meet operating system requirements, you can use whatever you like; the rest is up to you

My employees keep naming documents with hyphens in the name. For example, they might name a file Budget-2012-Final.xlsx. It is my position that hyphens should not be used in this way, and the document should be named Budget 2012 Final.xlsx. Please advise on the use of hyphens within file names.

Hyphens inside file names are legal, and you can use as many as you like, subject to the other rules for file names.

If you are having an argument with your employees about file naming conventions, that's something you just need to work out among yourselves. Whatever you decide, the file system will be there for you.

However, as I remember Sharepoint doesn't follow the same rules so when I tried to bulk load some users' documentaion folders into SharePoint I had problems with &'s, all understandable of course but confusing to teh end user. support.microsoft.com/…/2933738

I'm surprised that this query reached your level, Raymond. It's actually quite easy to find the file name rules in Windows, and I don't even need the MSDN: select a file in Explorer. Press F2. Press the / key. You'll get a tooltip with a list of the prohibited characters for file names. Hyphens aren't in that list, so therefore, they're allowed in file names. Sure, there are different rules for Windows vs. NTFS vs FAT vs. other file systems, but such a detailed answer need not be sent for such a frivolous query.

[Oh, they know what characters are legal in file names. In fact, they referenced the MSDN page in their question. But they weren't asking about what file names are legal. They wanted to know what file names are right. -Raymond]

My big frustration is when (some of) my colleagues insist on naming files like name_of_the_file.txt, just in case that file will some day be moved to another system (guess which one!) where lots of tools are not very good at handling file names containing spaces.

Or, (the same group of people) insisting that we consistently refer to the file by the "correct" casing, otherwise some people (and tools that they insist on using, imported from other OSes) might consider Name_Of_File and Name_of_file two different files. So, just to be on the safe side, they try to insist on honoring casing in ways that the file system we use certainly could care less about!

@icabod, @640k: It looks like (on Windows 7 at least) moving or copying a file with any spaces at the beginning of the name get trimmed off. It also does this when you attempt to create a file or directory with a space at the beginning (though this is more understandable). This is likely an Explorer issue and not an issue with Win32, and even then it's pretty harmless. Files with spaces at the beginning are likely created by users and typically are unintentional. I can't imagine a program actually depending on a file created with such a filename, and even in such a case there are workarounds available: command prompt, PowerShell, VBScript, etc.

@Zippy: Just because a ZIP file is a file doesn't make it any less a file system!

There's at least one file system type that has fairly extreme limitations, and it's not even a remote file system: ISO 9660-formatted CDs (see en.wikipedia.org/…/ISO_9660), so you have to be careful there.

On the *nix front, Samba does a pretty good job of mangling file names so that they don't have any illegal characters in them. Pity that the mangling turns them into completely opaque forms, though (like "NP29A6", etc.) It reminds me of when FAT long file names get corrupted.

For Raymond's original customer: whatever you choose, be consistent about it. There is also a new-fangled feature called a "directory" that can assist you in grouping like files together.

@12BitSlab: The phrasing "It is my position…" in the customer query suggests that what follows is the person's own opinion and not a business app requirement. If one of their applications required filenames without hyphens, then why wouldn't they have stated it? And what app can handle spaces, but not hyphens? The question sounds more like someone trying to use Microsoft to settle an internal dispute over file naming conventions.

@Zarat the APIs you're reading on don't care… they just pass the filenames to the underlying filesystem drivers, which will then accept or reject them based on their own rules.

@Joshua Based on the APIs used it is possible to construct files with illegal names… if you can construct an API call using \?C:whatever as the other guy said, you can reference that file successfully. Most likely you want to use del, which works.

This reminds me of my favorite web mail system that was no doubt written by people using a system whose filenames generally do not have spaces. Whenever you download an attachment, the spaces in its name get turned into underscores, so mailing a file to yourself changes its name.

To avoid ending up with two copies of any particular file I just use dashes or underscores instead of spaces.

An interesting bit of trivia about hyphens in Windows filenames is that leading hyphens are ignored by Explorer when sorting files. For example, given these files sorted by file name:

alphabet.txt

ponies.jpg

resume.doc

taxes.pdf

If you rename "resume.doc" to "-resume.doc", you end up with:

alphabet.txt

ponies.jpg

-resume.doc

taxes.pdf

Same goes for prepending multiple hyphens. This can be a handy trick when you're "disabling" a file by renaming it.

(Side note: It's quite sad that Michael Kaplan's blog was completely removed. It was a treasure trove that shouldn't have been so readily discarded by Microsoft, and that action makes me fear for the potential eventual loss of Raymond's blog).

[Explorer is not ignoring leading hyphens. CompareString is ignoring leading hyphens. (More accurately, punctuation has lower weight. It is used to break ties.) -Raymond]

@nil: just use the Yen symbol instead and write a layer over top that replaces it at runtime with NULL. auto fileHandle = CreateFile(L"¥.txt", GENERIC_WRITE, FILE_SHARE_READ, nullptr, CREATE_ALWAYS, 0, 0);

If only .NET were a legal file name (in Windows Explorer that is, the file system is OK with it) and there was a layer that allowed file names to be seamlessly natural language (or perhaps special Unicode characters defined for use in file names for forbidden characters without resorting to double-width and other kludges). Seriously: there is a need for question marks, quotes, colons and slashes to exist in file names in the real world.

But at least the customer is naming the files – you'd be amazed at the Government departments out there with network drives full of critical data named "New Document 1", "Copy of New Document 2" and variants thereof.

Exactly the feeling I have about personal names. Noone should be allowed to have a name containing a space.

Same with reports and messages and street addresses and the like: No identifying tag should be allowed to contain whitespace or any other character creating problems for your favorite software and file system.

To the h** with all cultural and social conventions! If people (and places, and street names, and …) want to take advantage of the modern computerized world, they just have to adopt to OSes and file systems that have trouble with whitespace. There is no way to support progress, except by dropping such silly expectations ss identifiers consisting of multiple words/names!

@Paul Coddington: See my post. *nix allows everything but NUL and / (which can bite hard). As for Japanese, etc., no problem after the adaption of UTF-8. The old Japanese encoding is a bad idea for lots of reasons.

Yes it bites hard when somebody puts a newline in a filename. Imagine that.

Thinking about it, there probably is a way to enforce the "no new files with hyphens" rule: create and install a file system filter driver. That way nothing can make such a file, not even the OS itself! Of course, it would break all sorts of programs but the customer is always right, correct? ;-)

@640k: What's triggering this security breach? Filename collisions? Explorer still captures those and prompts you about them. Changing a potential DLL name? Sure, but the DLL is still loadable regardless of whether it had the space in front of it or not, and this action is entirely user-driven inside an Explorer window; it's not a behavior of Win32 itself. It could cause programs to break if they, for some inexplicable reason, have a DLL named with spaces in the front, but that's not a security breach, that's user error.

A malicious program could theoretically use UI automation to take advantage of this behavior, but even so, if that's happened you're already screwed because hey, a malicious program has full access to your UI!

I occasionally want to use EN DASH (U+2013) in file names (like "Cayley–Hamilton theorem.docx"), but so far I have always decided not to because it might cause minor annoyances in some rare situations (like when I am forced to enter the file name manually in a text field which does not feature insertion of arbitrary Unicode characters via their code points — then I have to copy and paste the character, which is awkward).

@Fleet Command, come on, lighten up mate! Not everything in life is 0 or 1.

What you just said applies to yourself. By hypothesis:

– "If you can't make $100 more out of reading Raymond's blog or replying with such condescending tone without adding anything, please forget about it immediately, stop reading and don't even reply"

Now, don't take it personally mate, since I'm not actually going to tell this to you. It was just for the purpose of explanation. I'm sure you'd like your own guests to be a bit more comprehensive and… educated.

No, in most windows os (at least three I've tested) explorer.exe (an OS component) does not prompt the user when copying a folder and a file with leading spaces is automatically renamed.

2.

One potential security vulnerability is when copying a web site which is configured to prevent downloading of a file with leading spaces. The copy of the web site will have a renamed file, and it will be possible for users to download the file because the configured file name will not match. This might be an uncommon problem, but the real problem is that the result of the copy operation is unpredicatble, and thus there might exist infinite number of unknown security vulnerabilities.