16

I'm not asking about general syntactic rules for file names. I mean gotchas that jump out of nowhere and bite you. For example, trying to name a file "COM<n>" on Windows?

Improve this question

7 Answers 7

Reset to default
19

From: http://www.grouplogic.com/knowledge/index.cfm/fuseaction/view_Info/docID/111.

The following characters are invalid as file or folder names on Windows using NTFS: / ? < > \ : * | " and any character you can type with the Ctrl key.

In addition to the above illegal characters the caret ^ is also not permitted under Windows Operating Systems using the FAT file system.

Under Windows using the FAT file system file and folder names may be up to 255 characters long.

Under Windows using the NTFS file system file and folder names may be up to 256 characters long.

Under Window the length of a full path under both systems is 260 characters.

In addition to these characters, the following conventions are also illegal:

  • Placing a space at the end of the name
  • Placing a period at the end of the name

The following file names are also reserved under Windows:

  • aux,
  • com1,
  • com2,
  • ...
  • com9,
  • lpt1,
  • lpt2,
  • ...
  • lpt9,
  • con,
  • nul,
  • prn
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

aux is also not an allowed file name in Windows according to the article Adam mentions
I find the legitimacy of that article questionable, because it states that on Mac OS X, "File and folder names are not permitted to begin with a dot '.'", which is absolutely false.
It's not just the filenames you reserved under Windows, it's any of those device names followed by any extension whatsoever, e.g. COM5.foo and COM5.bar are illegal.
com0 and lpt0 are not allowed either, according to my windows
9

Full description of legal and illegal filenames on Windows: http://msdn.microsoft.com/en-us/library/aa365247.aspx

Improve this answer

2 Comments

Link-only answers are low value on Stackoverflow because they can move/die which renders your answer useless to researchers.
Additionally, the answer is far from complete as it includes in the prohibited characters list, "any other character that the target file system does not allow". But there is no information about the path restrictions of the different filesystems.
7

A tricky Unix gotcha when you don't know:

Files which start with - or -- are legal but a pain in the butt to work with, as many command line tools think you are providing options to them.

Many of those tools have a special marker "--" to signal the end of the options:

gzip -9vf -- -mydashedfilename
Improve this answer

Comments

7

As others have said, device names like COM1 are not possible as filenames under Windows because they are reserved devices.

However, there is an escape method to create and access files with these reserved names, for example, this command will redirect the output of the ver command into a file called COM1:

ver > "\\?\C:\Users\username\COM1"

Now you will have a file called COM1 that 99% of programs won't be able to open, and will probably freeze if you try to access.

Here's the Microsoft article that explains how this "file namespace" works. Basically it tells Windows not to do any string processing on the text and to pass it straight through to the filesystem. This trick can also be used to work with paths longer than 260 characters.

Improve this answer

4 Comments

I tried deleting the created file again, but del freezes in command line... Edit: I cant event kill cmd with task manager or process hacker... whats going on here?
Works fine for me. You can't del COM1 because of course that will try to access the serial port instead of the file and cause the process to lock up, waiting for a response from the serial port itself (exactly the reason why filenames like this are reserved and unavailable for use in the first place.) If you used the escape method in my answer to create the file, then you will have to use that to delete it as well: del "\\?\C:\Users\username\COM1"
Of course I did use the same \\?\ path to delete. I just wonder why my cmd froze. I gave up and reinstalled my complete OS. That fixed it pretty fast.
Maybe you didn't put quotes around it or made a typo? Reinstalling is a bit overkill, a reboot would have fixed the problem!
4

The boost::filesystem Portability Guide has a lot of good info.

Improve this answer

1 Comment

Link-only answers are low value on Stackoverflow because they can move/die which renders your answer useless to researchers.
3

Well, for MSDOS/Windows, NUL, PRN, LPT<n> and CON. They even cause problems if used with an extension: "NUL.TXT"

Improve this answer

2 Comments

Ran into this nonsense today. No idea why these filenames are illegal if you add extensions to them >:(
I think it's so programs like LINK.EXE (remember that?) which would accept one base filename, and then generate three different files with different extension. Then you could just type "nul" or "prn", and the program could just blindly add the extension, and things would still work.
1

Unless you're touching special directories, the only illegal names on Linux are '.' and '..'. Any other name is possible, although accessing some of them from the shell requires using escape sequences.

EDIT: As Vinko Vrsalovic said, files starting with '-' and '--' are a pain from the shell, since those character sequences are interpreted by the application, not the shell.

Improve this answer

5 Comments

If that's true, how do you create a filename with a forward-slash in it?
Yep, / is not valid in a filename on any filesystem type
@Basic Not necessarily. The NT kernel's object manager, which is essentially a virtual filesystem, only has one disallowed character: The backslash. Because it uses counted strings (Pascal/Rust-style strings), even NUL is valid in NT object manager paths.
@ssokolow True, however, there are no user-space tools that allow access to create those paths and thus no way to actually use them that wouldn't break everything (including explorer). Back in the day at school, we used the API to rename folders on XP and append a carriage return. Used to break explorer quite badly.
@Basic The original question doesn't specify whether the question is meant to be about command-line use, API use, etc. It's just asking about gotchas... and having a VFS API that supports NUL and / in path components and might be accessible via ported/portable libraries/utilities trying to break free of the 260-character Win32 path length limit and get some more Linux-like freedom certainly sounds like a potential gotcha to me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.