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. [email protected]
165 Forest St., Marlboro, MA 01752 (508)858-2600
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?
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
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 [email protected]
> 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. [email protected]
165 Forest St., Marlboro, MA 01752 (508)858-2600