On Tue, Aug 23, 2016 at 3:13 AM, eryk sun <eryk...@gmail.com> wrote: > 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.
Yes, it was Windows 7 (running in a VM under Debian Jessie, though I doubt that makes any difference). The Logs directory did exist (that's why I used that otherwise-odd choice of name). >> 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". I think it was FAT32 that we were using - it was a USB stick for sharing files between my Linux systems and his Windows. Linux was quite happy to put files into that FS that Windows refused to touch. (Also, due to some renamings, I ended up giving him two copies of a file that differed only in case - something like "Name The File Something.mkv" and "Name the File Something.mkv" - and Windows took issue with that too.) > 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. Yeah. They're nice straight-forward errors, as long as you're running on Windows. Detecting that on POSIX platforms and avoiding those names is why we have PureWindowsPath. If it doesn't currently have a quick little "is_valid", it could possibly benefit from one - PurePosixPath would simply "return '\0' not in name", while PureWindowsPath can do the more extensive checks with wildcard characters and stuff. >> 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 Great. So just as soon as all previous Windowses die....... Remind me how many people are still using Python 3.4 because they're still on Windows XP? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
