Skip to content

seekable() returns True on pipe objects in Windows #86768

Closed

Description

@nedsociety
mannequin
BPO 42602
Nosy @pfmoore, @vstinner, @tjguk, @zware, @eryksun, @zooba, @izbyshev

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-12-08.15:55:37.151>
labels = ['type-bug', '3.8', '3.9', 'expert-IO', '3.10', 'OS-windows']
title = 'seekable() returns True on pipe objects in Windows'
updated_at = <Date 2020-12-08.17:47:01.347>
user = 'https://bugs.python.org/nedsociety'

bugs.python.org fields:

activity = <Date 2020-12-08.17:47:01.347>
actor = 'izbyshev'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows', 'IO']
creation = <Date 2020-12-08.15:55:37.151>
creator = 'nedsociety'
dependencies = []
files = []
hgrepos = []
issue_num = 42602
keywords = []
message_count = 2.0
messages = ['382746', '382753']
nosy_count = 8.0
nosy_names = ['paul.moore', 'vstinner', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'izbyshev', 'nedsociety']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue42602'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

Linked PRs

Activity

  1. nedsociety commented on Dec 8, 2020

    nedsocietymannequin
    MannequinAuthor
    >>> 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.

  2. izbyshev commented on Dec 8, 2020

    izbyshevmannequin
    Mannequin

    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

  3. transferred this issue fromon Apr 10, 2022
  4. PeterJCLaw commented on Jun 7, 2022

    @PeterJCLaw
    Contributor

    Would a possible fix here be to check the file type within the (Windows) implementation of seek and seekable? Or is the necessary information not available by that point?

  5. vstinner commented on Jun 8, 2022

    @vstinner
    Member

    Maybe Python should get the handle from the file descriptor to call SetFilePointer() on it? Since lseek(fd) seems to silently ignores an error.

  6. added a commit that references this issue on Aug 11, 2026
  7. added
    type-featureA feature request or enhancement
    3.16new features, bugs and security fixes
    and removed on Aug 11, 2026
  8. added a commit that references this issue on Aug 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.16new features, bugs and security fixesOS-windowstopic-IOtype-bugAn unexpected behavior, bug, or errortype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions