why is lseek broken (>= 2.4.11) ?

why is lseek broken (>= 2.4.11) ?

[Phil Auld]

Hi folks,

There was a brief thread a couple of months ago about the change in 
lseek for block devices. The thread is here:

http://marc.theaimsgroup.com/?t=102406030100003&r=1&w=2

The change, which looks to have come in with 2.4.11, returns
EINVAL from an lseek on a block device attempting to set pos past 
the size of the device. 
 
This causes current versions glibc to exhibit non-SUS3 lseek behavior.

Are there plans to revert this? It seems that this is something that 
should be addressed in glibc first and then have the kernel change. 

There is no resolution in the thread above, nor is there any 
justification for the change. It just peters out.

Any thoughts?

Thanks,

Phil


-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: why is lseek broken (>= 2.4.11) ?

[Andrew Morton]

Phil Auld wrote:
> 
> Hi folks,
> 
> There was a brief thread a couple of months ago about the change in
> lseek for block devices. The thread is here:
> 
> http://marc.theaimsgroup.com/?t=102406030100003&r=1&w=2
> 
> The change, which looks to have come in with 2.4.11, returns
> EINVAL from an lseek on a block device attempting to set pos past
> the size of the device.
> 
> This causes current versions glibc to exhibit non-SUS3 lseek behavior.
> 
> Are there plans to revert this? It seems that this is something that
> should be addressed in glibc first and then have the kernel change.
> 
> There is no resolution in the thread above, nor is there any
> justification for the change. It just peters out.

What should the behaviour be?   The lseek should succeed,
but subsequent reads and writes return zero?

Re: why is lseek broken (>= 2.4.11) ?

[Andries Brouwer]

On Fri, Aug 09, 2002 at 01:48:47PM -0700, Andrew Morton wrote:

> What should the behaviour be?   The lseek should succeed,

Yes

> but subsequent reads and writes return zero?

Yes. The first read must return 0. Subsequent reads may return 0
or return the ENXIO error.

For read: "No data transfer shall occur past the current end-of-file.
If the starting position is at or after the end-of-file, 0 shall be
returned. If the file refers to a device special file, the result of
subsequent read() requests is implementation-defined."

ENXIO: "the request was outside the capabilities of the device".

For write: "If a write() requests that more bytes be written than
there is room for (for example, ... the physical end of a medium),
only as many bytes as there is room for shall be written.


Andries

Re: why is lseek broken (>= 2.4.11) ?

[Phil Auld]

Rumor has it that on Fri, Aug 09, 2002 at 11:13:06PM +0200 Andries Brouwer said:
> On Fri, Aug 09, 2002 at 01:48:47PM -0700, Andrew Morton wrote:
> 
> > What should the behaviour be?   The lseek should succeed,
> 
> Yes
> 
> > but subsequent reads and writes return zero?
> 
> Yes. The first read must return 0. Subsequent reads may return 0
> or return the ENXIO error.
> 
> For read: "No data transfer shall occur past the current end-of-file.
> If the starting position is at or after the end-of-file, 0 shall be
> returned. If the file refers to a device special file, the result of
> subsequent read() requests is implementation-defined."
> 
> ENXIO: "the request was outside the capabilities of the device".
> 
> For write: "If a write() requests that more bytes be written than
> there is room for (for example, ... the physical end of a medium),
> only as many bytes as there is room for shall be written.
> 

Agreed. That is what the standards say... And what userspace has come to expect.


Phil


> 
> Andries
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600