Hi Jonathan, On Fri, 12 May 2017, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > > On Windows, `(1|2)` is not a valid file name, and therefore the tag > > cannot be created as expected by the new test. > > > > So simply skip this test on Windows. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx> > > I wouldn't be surprised if there are filesystems used places other > than MINGW that also can't handle this test. Isn't this what some > tests use a FUNNYNAMES prerequisite for? Some tests do that. And they all implement that prereq themselves, differently. t3600 tries to create a file whose name contains a tab. t4135 tries to create a file whose name contains a tab, but only if the MINGW prereq is set. t9903 tries to create a file whose name contains a newline. It seems, therefore, that the existing FUNNYNAMES are already in disagreement, and as you point out below, the file name in question contains neither a tab nor a newline. So we would introduce *yet another* disagreeing FUNNYNAMES. Besides, in some hopefully not so far future, our default refs backend may not depend on the current platform's file system's idionsyncracies. So maybe we do not even want the MINGW nor the FUNNYNAMES prereq... > In this example, it's the pipe that's not allowed, not the > parenthesis, right? (At least I have some memories of naming files > with some parentheses.) You would be correct in that assumptions. Long names on NTFS can contain parentheses. > Would something like > > test PIPE_IN_FILENAME ' > >"a|b" && > test -f "a|b" > ' > > work? No. Remember: on Windows, there is no Unix shell. (Actually, there is Bash on Ubuntu on Windows, and with the Creators Update, it became truly awesome, I am a big fan of it. But that is besides the point here: Git for Windows needs to support Windows versions older than Windows 10, where Bash on Ubuntu on Windows is simply unavailable.) So what Git for Windows has to do is quite a burden: we ship with MSYS2, kind of a light-weight version of Cygwin, to run our shell scripts. (I would wager a bet that at least a third of the bug reports relate to the POSIX emulation layer we ship to allow us to run Bash and Perl, but even that is only half the truth: tracking down those bugs takes easily the majority of my bug hunting/fixing time, hands down.) The test suite is no exception. I may have ranted about this about six dozen times already, so I'll save me the time. Just pretend that you now read seven long paragraphs describing how much it sucks to run the test suite on Windows. Take home message: Unix shell scripting is good for personal use. Don't use it in applications, not if you want to stay portable. Just don't. Back to the subject: The MSYS2 emulation layer inherits a neat trick from Cygwin, where it *can* create file names containing pipe symbols. They will be quietly mapped into a private UTF-8 page, and when Cygwin or MSYS2 read the file back, the file name maps from this page back to ASCII transparently. That strategy is all good and dandy, as long as you stay within the POSIX emulation layer. Git for Windows avoids the POSIX emulation layer as much as possible, for speed, and also for robustness. Which means that Git does *not* map the file names using said private UTF-8 code page. And therefore, your test would succeed (because the shell script would stay within the POSIX emulation layer, which creates that file using above-mentioned strategy), but Git (being a regular Win32 program) *still* would fail to create said file. Ciao, Dscho