QuickCheck PathName function may produce bad paths on Windows

[geekosaur]

Describe the bug
A review of the QuickCheck instances (as part of #9241 debugging) revealed that arbitraryShortPath does not check for illegal characters on Windows, nor for device names (CON, LPT, etc.) which cannot be used as file or directory names.

To Reproduce
See https://github.com/haskell/cabal/blob/master/Cabal-QuickCheck/src/Test/QuickCheck/Instances/Cabal.hs#L508-L509

Expected behavior
It should produce pathnames valid on any system that we support.

System information

• Operating system: Windows
• cabal, ghc versions: any

[geekosaur]

From Microsoft:

The following reserved characters:

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

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

CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt and NUL.tar.gz are both equivalent to NUL. For more information, see Namespaces.

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp".

[geekosaur]

I would also omit ~ because it can be used for short file names on Windows and is special in zsh which may matter for Mac CI.

[geekosaur]

While I'm looking at this, I find myself wondering if the Arbitrary instances for InstallDirs and PathTemplate are safe. Perhaps someone familiar with one or the other could comment while I'm poking at the original issue.

[geekosaur]

I am locally testing a patch.

[geekosaur]

mrrr. So the a in InstallDirs a is FilePath or PathTemplate or a variant of one of those two (e.g. Maybe FilePath), and afaict we are using the standard Prelude FilePath and not e.g. the one from filepath. Which means arbitrary in the instance for InstallDirs is String? and the same for PathTemplate? That sounds like we have the same problem that needs to be fixed, except more so because NUL will be allowed, plus PATH_MAX.

This said, I am not sure that any of these are used for anything other than generating test cabal files, so all this may be pointless.

[Mikolaj]

Which means arbitrary in the instance for InstallDirs is String?

I had that impression as well.

because NUL will be allowed

I hope that's not true, because NUL is not a valid unicode character and String = [Char]. But I may be wrong.

This said, I am not sure that any of these are used for anything other than generating test cabal files, so all this may be pointless.

Even if so, I can easily imagine somebody adding a test for their PR by using the Arbitrary instances and writing files with these names. And we'd get a fragile test that fails half a year later. Or we may already have one.

BTW, I now remember somebody worked on Windows filename compatibility a year or two ago. Perhaps in the filename parsers, not in Arbitrary instances. So maybe there is some code that could be shared and augmented together.

[geekosaur]

NUL is a perfectly cromulent Unicode codepoint and can be encoded as \NUL or \0 in Haskell for use in strings; it's just not a valid filename character. For example, from my xmonad config:

  case nw of
    Nothing -> return ()
    Just s -> when (s == "mate-notification-daemon\NULMate-notification-daemon\NUL") $
                boing' "onboard-key-feedback"

which is an encoded window property, not a filename.

[Mikolaj]

Wow, I didn't know. So it's not represented as the zero byte, but it's still NUL and still not permitted in file names. Man, this is complex.

[geekosaur]

Pardon? It's definitely a zero byte. Unlike C, most modern languages including Haskell have strings with sizes instead of terminators, so NUL is entirely legal. That's what unix was checking for (incorrectly, making the same mistake it was checking for but in reverse!).