fdopen() not guaranteed to have Python semantics

[movement]

BPO	1461855
Nosy	@birkenfeld

^{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 = <Date 2006-03-31.20:15:19.000>
created_at = <Date 2006-03-31.04:37:58.000>
labels = ['library']
title = 'fdopen() not guaranteed to have Python semantics'
updated_at = <Date 2006-03-31.20:15:19.000>
user = 'https://bugs.python.org/movement'

bugs.python.org fields:

activity = <Date 2006-03-31.20:15:19.000>
actor = 'movement'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2006-03-31.04:37:58.000>
creator = 'movement'
dependencies = []
files = []
hgrepos = []
issue_num = 1461855
keywords = []
message_count = 5.0
messages = ['27970', '27971', '27972', '27973', '27974']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'titty', 'movement']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1461855'
versions = ['Python 2.4']

[movement]

The specification for seek() says:

 seek(  	offset[, whence])
    Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write.

Consider operating on an fdopen()ed file. The Python
source simply calls into the OS-provided fdopen():

http://pxr.openlook.org/pxr/source/Modules/posixmodule.c#3530

However, the POSIX standard

http://www.opengroup.org/onlinepubs/009695399/functions/fdopen.html

says:

"Although not explicitly required by this volume of
IEEE Std 1003.1-2001, a good implementation of append
(a) mode would cause the O_APPEND flag to be set."

Thus, to ensure Python semantics, Python's fdopen()
must perform an fcntl() to ensure O_APPEND is set.

For example, on Solaris, this optional O_APPEND
behaviour is not applied:

http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/stdio/fdopen.c?r=1.22#97

This has recently caused serious problems with the
Mercurial SCM.

[titty]

Logged In: YES
user_id=17929

freebsd 4.11 shows the same behaviour.

import fcntl
import os

def test_fdopen_append():
    
    def is_append(fd):
        return bool(fcntl.fcntl(fd, fcntl.F_GETFL) &
os.O_APPEND)


    fd = os.open("foo.txt", os.O_RDWR | os.O_CREAT)
    assert fd != -1
    
    print "is_append:", is_append(fd)
    
    f=os.fdopen(fd, 'a')
    print "after fdopen is_append:", is_append(fd)

assert is_append(fd)

test_fdopen_append()

[titty]

Logged In: YES
user_id=17929

patch here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1462227&group_id=5470&atid=305470

[birkenfeld]

Logged In: YES
user_id=849994

Applied patch in rev. 43501, 43502.

[movement]

Logged In: YES
user_id=53034

Shouldn't the documentation now state this change in
behaviour? i.e. if fdopen() fails, O_APPEND may still have
become set.

This behaviour seems a little odd to me in fact. Can't we set
fcntl after a successful fdopen()[1]? Also wouldn't it be
useful to point to the standards sentence I quote above?

[1] not sure what the ALLOW_THREAD thing does?