Skip to contentSkip to conversation

sendfile doesn't work with O_APPEND

Bug 82841 bugzilla-daemon-590EEB7GvNiWaY/[email protected] 1 participant 4 messages Aug 21, 2014 – May 5, 2015 2 messages not in the archive Man-pages: manual pages for Linux -- Sections 2, 3, 4, 5, and 7

lore
Share & tools
lore
#2 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=82841

Alan <alan-qBU/[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |alan-qBU/[email protected]
          Component|Other                       |man-pages
           Assignee|io_other-ztI5WcYan/[email protected] |documentation_man-pages@ker
                   |rg                          |nel-bugs.osdl.org
            Product|IO/Storage                  |Documentation

--- Comment #1 from Alan <alan-qBU/[email protected]> --- O_APPEND is not supported for sendfile().

It's documented in the splice() manual page but not for sendfile so I've moved this to a documentation bug

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=82841

--- Comment #2 from Jason Newton <[email protected]> --- (In reply to Alan from comment #1)

Quoted 4 lines

O_APPEND is not supported for sendfile().

It's documented in the splice() manual page but not for sendfile so I've moved this to a documentation bug

OK so this quirk was not out in the open in documentation - before I opened this bug report I read a few years old discussion:
http://fixunix.com/kernel/543017-splice-vs-o_append.html

Most of what they're talking about is splice, not sendfile. They might use the same implementation but sendfile should be O_APPEND safe as there is no specifiable offset in the output filedescriptor. Is there a reason to not support it?

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#4 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=82841

--- Comment #3 from Alan <alan-qBU/[email protected]> --- sendfile is just a wrapper around splice()

Whether it could therefore support O_APPEND is a good question - but one that would need asking and discussing on the lists not here, and someone to contribute the patches to do so.

In the meantime we ought to get the man page fixed.

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#5 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=82841

Michael Kerrisk <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
                 CC|                            |[email protected]
         Resolution|---                         |CODE_FIX

--- Comment #4 from Michael Kerrisk <[email protected]> --- I added the following text in ERRORS for sendfile(2).

EINVAL out_fd was has the O_APPEND flag set. This is not cur‐
rently supported by sendfile()

So, am closing this bug now.

Signature · 5 lines
You are receiving this mail because:
You are watching the assignee of the bug.--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html