On Mon, Aug 22, 2016 at 4:18 PM, Chris Angelico <ros...@gmail.com> wrote: > >> The CON device should work if the process is attached to a console >> (i.e. a conhost.exe instance). > > No, I used Pike (to avoid any specifically-Python issues or > protections) running in a console. Attempting to write to "Logs/con" > wrote to the console, so I know the console device is active. > Attempting to write to "Logs/con.txt" failed as described.
What version of Windows is this? If it's Windows 7 I'll have to check that later. If "Logs" is an existing directory, then both "Logs/con" and "Logs/con.txt" should refer to the console. If "Logs" doesn't exist, then both should fail. Virtual DOS devices only exist in existing directories. >> > I wouldn't accept file names from untrusted sources on *any* system >> >> There are still desktop applications that ask users to name their files. > If the user owns the computer, s/he should be allowed to attempt any > name, and there'd simply be some that fail - same as any other invalid > characters Silently writing a file to a (possibly hidden) console or NUL device is not the same thing as failing with an error. If users explicitly open "NUL" or "\\.\NUL", I can detect that, and I have no problem with it (with some reservations about the former). But if they open files like "C:\Users\JoeUser\Documents\Nul.20160822.doc", I want to make sure they know that they just asked to save to "\\.\NUL". It's not a common problem. I just find the system's behavior abhorrent. I'd like to have a manifest setting that opts the process out of this stupid DOS legacy behavior. > Windows won't let you put a colon or question mark in a file name, for > instance, > which annoys my brother no end when I give him files like > "What's Up, Doc?.mkv" or "Operation: Rabbit.mkv") A colon is reserved for NTFS streams, so it can silently bite you. If you get an error for "Operation: Rabbit.mkv", you're probably using FAT32. On NTFS that creates a file named "Operation" with a $DATA stream named " Rabbit.mkv". Every NTFS file has at least the anonymous stream, e.g. "filename::$DATA". Every NTFS directory has at least the $I30 stream, e.g. "dirname:$I30:$INDEX_ALLOCATION". Directories can also have named $DATA streams. As to question mark and other wildcard characters, those are all unambiguously handled as exceptions. No Microsoft filesystem allows them because wildcard matching is baked into the system, such as the FileName parameter of NtQueryDirectoryFile when listing the contents of a directory. I guess no one on the NT I/O team wanted to bother with the possibility of escaping these wildcards since they weren't allowed in DOS filenames. FsRtlIsNameInExpression [1] is the kernel-mode filesystem function that implements wildcard matching. Note that DOS wildcard semantics are implemented by DOS_STAR (<), DOS_QM (>), and DOS_DOT ("). FindFirstFile has to convert DOS wildcard patterns to NT semantics before calling NtQueryDirectoryFile. It's not as simple as substituting the corresponding DOS_ wildcard. Pipe and ASCII control characters are also reserved, except not in NTFS stream names. Reserving pipe is just a DOS legacy. I don't think it's used for anything internally. > or over-long names or anything like that. Good news. In Windows 10, systems and applications can opt in to using long paths with up to about 32760 characters. Python 3.6 will be opting in. [1]: https://msdn.microsoft.com/en-us/library/ff546850 -- https://mail.python.org/mailman/listinfo/python-list