Eryk Sun <eryk...@gmail.com> added the comment:
> lseek() succeeds on pipes on Windows, but is nearly useless lseek isn't meaningful for pipe and character files (i.e. FILE_TYPE_PIPE and FILE_TYPE_CHAR). While SEEK_SET and SEEK_CUR operations trivially succeed in these cases, the underlying device simply ignores the current file position. I think it would be reasonable to fail these cases instead of succeeding misleadingly. When a file is opened for synchronous access, its FilePositionInformation is managed by the I/O manager, not the device or file system. All the I/O manager does is get or set the CurrentByteOffset value in the File object [1]. It doesn't matter whether the device actually uses this information. Regarding the observed SEEK_END behavior, the named-pipe file system (NPFS) supports querying the FileStandardInformation of a pipe, in which it sets the EndOfFile value as the number of bytes available to be read from the pipe's inbound (server-side) queue. So SEEK_END (or WinAPI FILE_END) does provide some information to us, but it's misleading because the seek itself is meaningless. [1]: https://msdn.microsoft.com/en-us/library/windows/hardware/ff545834 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34780> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
