Re: [PATCH 6/5] NUL hack to create_file()

On Thu, 29 May 2008, Marius Storm-Olsen wrote:

Johannes Sixt said the following on 29.05.2008 08:33:

quoted

Junio C Hamano schrieb:

quoted

This is not meant for application to the mainline.  It allows your git to
refuse to create a blob whose name is "nul".

It's not just about "nul"; these won't work either: "aux", "prn", "con",
"com\d+", "lpt\d+", neither do "$one_of_these.$some_extension". And all of
that regardless of the case!

See http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

Definitely, we don't ever want to have such special-casing somewhere in git.

They _can_ be used by using the UNC notation:
    \\?\<drive letter>:\<path>\nul
Do you think we should special-case that, or simply fail?

Perhaps we should see if we can get an open() that always uses that 
notation for the actual system call? I doubt we want to support the 
DOS-ish meanings even if the user provides them as input sources. If it's 
not actually a problem with the underlying storage mechanism, but rather a 
flaw in the POSIX implementation for Windows, we should fix that (or do 
something in compat to work around it) instead of failing in any way to 
support it in git. Of course, people on Windows using projects with these 
filenames will probably run into problems with other tools, but at least 
git will behave properly.

On the other hand, I bet there are going to be real issues with filenames 
with backslashes in them.

	-Daniel
*This .sig left intentionally blank*