On Thu, 29 May 2008, Marius Storm-Olsen wrote: > Johannes Sixt said the following on 29.05.2008 08:33: > > Junio C Hamano schrieb: > > > 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
