Filenames

[Toby Nelson]

Actually, the first sentence in that paragraph (about putting quotes around filenames with spaces) stands alone. Nothing else in the sentence is dependent on it. So quotes and backslashes anywhere in the filename always need to be escaped with a backslash.

Ok.

No, only double quote and backslash are supported.

Ok. To clarify, if a backslash is follow by something else (i.e. not double quote or backslash), the backslash should be interpreted as a regular character as part of the filename itself and not as a directory separator. (Note the spec says "The \ character itself must be doubled up (\\) in order to be used to specify a sub-directory...")

I would hope that that this:

    s\\\hello.png

would properly be interpreted as a file "\hello.png" in subdirectory "s" (this is treating the first pair of backslashes as the directory separator), rather than file "hello.png" in a subdirectory named "s\" (regarding the final pair of backslashes as the directory separator).

Spaces are allowed in model reference lines, and quoting of filenames is not allowed. Everything from the first character of the model reference filename to the end of the line should be treated as the filename. I believe that the quote wrapping for TEXMAP was done purely so that other tokens could be added after the filename, and that has never been an issue with model filenames.

Yes, that makes sense, except I would note that for model reference lines, whitespace before the start and after the end of the filename (including the file's extension) should probably be ignored (so you can't have a filename starting with a space for instance).

Filenames for both textures and model references (outside library parts) are chosen by the end user. As such, we have to assume that they will choose anything that their operating system allows them to choose.

Agreed, the user can choose whatever they want.

So adding to what is already there (along with separate parts library filename restrictions) is counter-productive.

I'm adding characters that have special meanings in Windows filenames. I'm not saying these should be banned, just discouraged for the purposes of cross-platform compatibility. In particular I think that parsing software *should* cope with as many of these as it possibly can (ideally all of them). However a user creating or using files with any of these characters present is still more prone to cross platform compatibility problems IMHO.

Colon won't work on Windows (and probably also not on Mac).

Agreed. It's use should therefore definitely be discouraged.

Some of the others cause problems on a command line due to shell interpretation, but that shouldn't affect software that is reading the files.

People use shells, and I bet there are Windows file APIs for which they have special meaning. I'd regard them as risky.