Re: splice() and file offsets

["Michael Kerrisk" <mtk-manpages@gmx.net>]

Jens,

> > I'm still not clear here.  Let me phrase my question another way:
> > why is it that the presence or absence of off_out affects whether
> > or not splice() changes the current file offset for fd_out?
> 
> The logic is simple - either you don't give an explicit offset, and the
> current position is used and updated. Or you give an offset, and the
> current position is ignored (not read, not updated).

Yes, I understand what the code is doing, but *why* do 
things this way?  (To put things another way: why not *always 
have splice() update the file offset?)  I realise there may be
some good reason for this, and if there is, it will go into the
man page!

> > > It's identical to how sendfile() works.
> > 
> > But it isn't: sendfile() never changes the file offset 
> > of its 'in_fd'.
> 
> Ehm, yes it does. Would you expect the app to do an appropriate lseek()
> on every sendfile() call?

No!  It does not!  See the sendfile.2 man page: "sendfile() 
does not modify the current file offset of in_fd."  
(You had me worried -- I just now went and *tested* 
the operation of sendfile().)  The app does not need to 
do an lseek() call because the 'offset' argument is *always* 
updated with the new "virtual" offset.  This is part of why I 
am disturbed/confused: sendfile() always updates its 'offset' 
argument and *never* changes the file offset; splice() only 
does that if its 'offset' argument is non-NULL.

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.