Filenames

[Travis Cobbs]

Ok.

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...")

No, a backslash followed by any character other than backslash or double quote is invalid and should cause the entire line to be rejected by LDraw-compliant software.

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).

An LDraw program seeing that texture filename should reject the TEXMAP line entirely.

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).

You are correct; I misspoke. The main LDraw spec later states: Any leading and/or trailing whitespace must be ignored.

Agreed, the user can choose whatever they want.

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.

In my personal opinion, only colon should be mentioned at all (and it isn't on the current list of characters to avoid).

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

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

I don't believe that native file APIs on any OSes have problems with any characters that are valid to use, and filenames referenced inside LDraw files should not ever be accessible from the command line. Any shell script that wants to parse an LDraw file and pass bits and pieces around already is going to have to deal with spaces in the filenames. And I still feel that these specs aren't an appropriate place to try to enumerate potentially problematic characters when the people using the software to create LDraw files will never read the specs.