[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates c

From: Bruno Haible
Subject: Re: [Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates corrupt images
Date: Fri, 07 Sep 2018 23:12:32 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-134-generic; KDE/5.18.0; x86_64; ; )

Eric Blake wrote:
> > I have done some experiments and find out that
> > the behavior of lseek with whence set to SEEK_DATA is different from the 
> > behavior of Linux's lseek.
> > 
> > If the supplied offset is in the middle of a data region, it returns the
> > start of the next data region.  There may be many data regions in a big
> > file even though it has no hole.
> > 
> > return value of lseek with whence set to SEEK_DATA:
> > 
> > |--(offset)--Data----|(return value)----Data----|
> > |--(offset)--Data----|----Hole----|(return value)----Data----|
> Ouch. That's a nasty bug in MacOS, and gnulib should be taught to work 
> around broken lseek(SEEK_DATA)

Why would that be important? As far as I understand the SEEK_DATA facility
from the man page [1], the most immediate way to make reasonable use of it is
to call
   offset = lseek (fd, SEEK_DATA, offset);
   offset = lseek (fd, SEEK_HOLE, offset);
alternatingly. On Linux, you may start with SEEK_DATA or SEEK_HOLE; on
macOS, you would need to start with SEEK_HOLE because starting with
SEEK_DATA won't work. Is it a _that_ big problem?


[1] http://man7.org/linux/man-pages/man2/lseek.2.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]