On 04/22/2011 05:28 AM, Markus Trippelsdorf wrote: > On 2011.04.22 at 00:50 -0400, Christoph Hellwig wrote: >> [Eric: please don't drop the Cc list, thanks!] That's the fault of gmane. My apologies for not being subscribed in the first place, and for gmane's refusal to cc all. Now that I'm on the cc-chain, it won't happen again for this thread. >>> lseek's purpose is to reposition the file position, so I'd imagine >>> this is just a bug in the man page. >> >> I would be surprised if the bug is around for such a long time, but >> otherwise I concur. > > It's a bug. Let me quote what Jeff Bonwick wrote on his blog: > > »I'm not sure where you got the impression that either SEEK_HOLE or > SEEK_DATA doesn't set the file pointer. They do. (If they didn't, that > would be weird, and we'd call it out explicitly.)« > > http://blogs.sun.com/bonwick/entry/seek_hole_and_seek_data That blog also mentioned the useful idea of adding FIND_HOLE and FIND_DATA, not implemented in Solaris, but which could easily be provided as additional lseek constants in Linux to locate the start of the next chunk without repositioning and which could ease application programmer's life a bit. After all, cp wants to know where data ends without repositioning (FIND_HOLE), read() that much data which repositions in the process, then skip to the next chunk of data (SEEK_DATA) - two lseek() calls per iteration if we have 4 constants, but 3 per iteration if we only have SEEK_HOLE and have to manually rewind. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
