Win32/Path.inc: "NUL" is not regular file (clang -o NUL fails)

[llvmbot]

Bugzilla Link	8520
Resolution	FIXED
Resolved on	Aug 21, 2011 09:06
Version	trunk
OS	Windows XP
Blocks	llvm/llvm-bugzilla-archive#9099
Reporter	LLVM Bugzilla Contributor
CC	@AaronBallman

Extended Description

C:\path\to> clang foo.c -S -o nul
error: unable to rename temporary 'nul-000000' to output file 'nul': 'Can't move

  'nul-000000' to 'nul': Cannot create a file when that file already exists.

'
1 error generated.
clang: error: unable to remove file:

===

It is due to sys::Path::isRegularFile().

My workaround is below. It seems there is no way to detect
reserved filenames ("nul", "con", &c) with Win32API.

--- a/lib/System/Win32/Path.inc
+++ b/lib/System/Win32/Path.inc
@@ -369,6 +369,9 @@ bool
Path::isRegularFile() const {
if (isDirectory())
return false;

• if (getBasename().size() == 3

•  && memcmp(getBasename().data(), "nul", 3) == 0)
  

• return false;
  return true;
  }

[llvmbot]

It was Bug 5568 :)

• Clang tries to remove /dev/null

[llvmbot]

Fixed temporally in r127724, to let only "nul" recognized.

We have to detect as many special files as possible.

[llvmbot]

Fixed temporally in r127724, to let only "nul" recognized.

We have to detect as many special files as possible.

See this MSDN article for the restrictions on filenames in Windows.
http://msdn.microsoft.com/en-us/library/aa365247.aspx
(You can get to that link from Wikipedia: http://en.wikipedia.org/wiki/Filename#cite_note-win-3 )

There is a long list, related to all the special device names inherited from DOS (and maybe even earlier!)
For example, PRN, AUX, CON, etc.

Here is the relevant quote:

"Do not use the following reserved device names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces.
"

[llvmbot]

Fixed in r138213 by Aaron!

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#9099