Does it `sanitize` reserved name like CON or COM1 on Windows?
Clicking at [src] in the documentation does not show any special handling of things like
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
(source)
Note that it can also be complexier like aux.txt
Is it because of online documentation isn't for windows or it is not handled?
Not currently handled, but would be a great (and simple) addition.
It looks like any name starting with those values and a period are also invalid.
If sanitized is indented to be used for security, this would be a necessary addition.
It should probably stated in the documentation whether the function is expected to be secure (there may be even advisories about it in this case) or not. Transforming a hostile string into a filename (secure to use, but still mostly representing the string in question) is a hard-ish task.
Does it chop off too long filename by the way?
The intent wasn't security, but to make sure that e.g. somebody developing on Linux wouldn't accidentally use path names that fail on Windows.
We call sanitized on every platform for the sake of consistency, but I'll probably handle the "reserved" names on Windows only (to avoid a breaking change, since those names would fail on Windows anyway).
The intent wasn't security
Then either the scope and intent should be enlarged to include uses for security (e.g. the name is 100% guranteed to be "no tricks"), or phrase like "the function should not be used for security, to sanitize hostile user input" or "it is possible that sanitized returns a tricky filename on some platforms".
Maybe the latter better suits the purpose of this library, as the former may require building and maintaining blacklists of names per various platforms and may be more (not autorun.inf, not .git and so on).
Agreed; I can add a clarification to the docs. It definitely isn't intended to be used on user input, but programmer input - to create a directory structure for their app data in the right place.
A secure filename sanitizer may worth a separate crate. It may be full of heuristics and tweaks (like "no unicode + abbreviate + supplement with a short hash" or "please make a 8.3 filename")