[issue42602] seekable() returns True on pipe objects in Windows

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

Yes, despite that MSVCRT knows the type of the file descriptor because it calls 
GetFileType() on its creation, it doesn't check it in lseek() implementation 
and simply calls SetFilePointer(), which spuriously succeeds for pipes. MSDN 
says the following[1]:

Calling the SetFilePointer function with a handle to a non-seeking device such 
as a pipe or a communications device is not supported, even though the 
SetFilePointer function may not return an error. The behavior of the 
SetFilePointer function in this case is undefined.

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointer

--
components: +Windows
nosy: +eryksun, izbyshev, paul.moore, steve.dower, tim.golden, vstinner, 
zach.ware
versions: +Python 3.10, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42602] seekable() returns True on pipe objects in Windows

[Myungbae Son]

New submission from Myungbae Son :

>>> import os
>>> r, w = os.pipe()
>>> os.lseek(w, 10, 0)
10
>>> wf = open(w, 'w')
>>> wf.seekable()
True

This happens on Windows. Consequently seek() works for these objects but they 
seems to be no-op. This may confuse libraries that depend on seeking.

The named pipe objects (via CreateNamedPipe -> open_osfhandle -> open()) 
exhibit the same behavior.

--
components: IO
messages: 382746
nosy: nedsociety
priority: normal
severity: normal
status: open
title: seekable() returns True on pipe objects in Windows
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com