On 2026-10-18 07:13, Kamila Szewczyk wrote:
I think that extra checks should be added, where applicable, to reject [:(<>)\r].
Ideally the only bytes we should prohibit in file names should be '\0' and '\n' (both of these due to POSIX restrictions). I suppose it'd also be OK to reject file names that contain encoding-error bytes. If we can't handle valid characters for some other reason, it's better to reject them early rather than to fail mysteriously. If that's the case for the characters you list, that's a good way to go. Though it'd be better to fix the mysterious problems, we may not have time to do so. Of the characters you list, rejecting ":" seems a bit much. I assume that this is in a context like $PATH. It makes sense to reject ":" in those contexts, but I don't see why to reject it elsewhere. Whatever we reject, we should document for users.
I have a suspicion that something similar might be happening on Win32 platforms (MSYS, and so on) with file names "nul", "con", and so on, but I don't have the capacity to test that right now.
Yes, it's not worth our time worrying about those, except perhaps to document them.
