A Google engineer has published a detailed exposé on how Microsoft Windows handles file and directory pathnames (as opposed to how it is documented to handle them) <http://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html> (found from <http://www.theregister.co.uk/2016/03/01/windows_path_hacks/>). Most of it, it could be argued, makes some sort of sense from a backward-compatibility rationale. Except for the reserved device names (PRN, NUL, CON etc): Now if just specifying these paths explicitly was all that this process handled it would be annoying but not the end of the world. However it’s much worse. The conversion process actively tries to convert any path with the device name last, even if the path is a Drive Absolute path. To make matters even worse the device name can have arbitrary trailing characters as long the trailing characters are separated from the device by a dot or a colon. The name can then also have trailing spaces. ... Why it does the check is beyond me as it seems to serve no actual purpose. Also note the removal of trailing suffixes, which can come in handy if something is actively trying to guard against this behavior. For example, if an application was mindful and was checking for a filename that matched one of the reserved names you can just bypass that check by appending an arbitrary suffix.