From nobody@FreeBSD.org  Tue Nov 22 20:34:28 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 9BFED106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 22 Nov 2011 20:34:28 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 82C738FC18
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 22 Nov 2011 20:34:28 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pAMKYSnb091223
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 22 Nov 2011 20:34:28 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id pAMKYSiR091222;
	Tue, 22 Nov 2011 20:34:28 GMT
	(envelope-from nobody)
Message-Id: <201111222034.pAMKYSiR091222@red.freebsd.org>
Date: Tue, 22 Nov 2011 20:34:28 GMT
From: Alexander Best <arundel@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [patch] lseek(2) may return successful although no seek operation was actually performed
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         162765
>Category:       docs
>Synopsis:       [patch] lseek(2) may return successful although no seek operation was actually performed
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 22 20:40:01 UTC 2011
>Closed-Date:    
>Last-Modified:  Sun Sep 02 16:52:39 UTC 2012
>Originator:     Alexander Best
>Release:        10.0-CURRENT
>Organization:
>Environment:
FreeBSD otaku 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r227803M: Mon Nov 21 23:05:28 CET 2011     arundel@otaku:/usr/obj/usr/subversion-src/sys/ARUNDEL  amd64
>Description:
in certain situations lseek() will return successful although no seek was performed. this can happen when operating on devices that don't support seeking (older tape drives) or when operating on changeable media devices (such as DVD or Blu-ray devices) without a medium inserted.

the attached patch fixes the lseek(2) man page by adding several entries to the BUGS section, along with updating the POSIX compliance to the latest specifications.

please note that the real issue doesn't seem fixable atm. lseek() was never designed to confirm a seek operation, but to merely request it.

the issue was extensively discussion in this thread:

http://lists.freebsd.org/pipermail/freebsd-hackers/2011-November/036842.html (alternative link: http://docs.freebsd.org/cgi/mid.cgi?20111115202450.GA73512)

cheers.
alex
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2
index 874c523..209af51 100644
--- a/lib/libc/sys/lseek.2
+++ b/lib/libc/sys/lseek.2
@@ -28,7 +28,7 @@
 .\"     @(#)lseek.2	8.3 (Berkeley) 4/19/94
 .\" $FreeBSD$
 .\"
-.Dd April 5, 2007
+.Dd November 21, 2011
 .Dt LSEEK 2
 .Os
 .Sh NAME
@@ -113,10 +113,9 @@ of the existing end-of-file of the file.
 If data is later written
 at this point, subsequent reads of the data in the gap return
 bytes of zeros (until data is actually written into the gap).
-.Pp
-Some devices are incapable of seeking.
-The value of the pointer
-associated with such a device is undefined.
+However, the
+.Fn lseek
+system call does not, by itself, extend the size of a file.
 .Pp
 A
 .Qq hole
@@ -197,13 +196,43 @@ is associated with a pipe, socket, or FIFO.
 The
 .Fn lseek
 system call is expected to conform to
-.St -p1003.1-90 .
+.St -p1003.1-2008 .
+.Pp
+The
+.Dv SEEK_HOLE
+and
+.Dv SEEK_DATA
+directives, along with the
+.Er ENXIO
+error, are extensions to that specification.
 .Sh HISTORY
 The
 .Fn lseek
 function appeared in
 .At v7 .
 .Sh BUGS
+If the
+.Fn lseek
+system call is operating on a device which is incapable of seeking,
+it will request the seek operation and return successfully,
+even though no seek was performed.
+Because the
+.Ar offset
+argument will be stored unconditionally in the file descriptor of that device,
+there is no way to confirm, if the seek operation succeeded or not
+(e.g. using the
+.Fn ftell
+function).
+Device types which are known to be incapable of seeking include
+tape drives.
+.Pp
+The
+.Fn lseek
+system call will not detect whether media are present in changeable
+media devices such as DVD or Blu-ray devices.
+A requested seek operation will therefore return sucessfully when no
+medium is present.
+.Pp
 This document's use of
 .Fa whence
 is incorrect English, but is maintained for historical reasons.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-doc 
Responsible-Changed-By: arundel 
Responsible-Changed-When: Tue Nov 22 20:45:29 UTC 2011 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162765 

From: Alexander Best <arundel@freebsd.org>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/162765: [patch] lseek(2) may return successful although no seek operation was actually performed
Date: Tue, 22 Nov 2011 21:52:56 +0000

 --fdj2RfSjLxBAspz7
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 here's a revised patch (comma removed after "confirm"), as suggested by warren
 block. thanks. :)
 
 cheers.
 alex
 
 --fdj2RfSjLxBAspz7
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="lseek.2.diff3"
 
 diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2
 index 874c523..1db5891 100644
 --- a/lib/libc/sys/lseek.2
 +++ b/lib/libc/sys/lseek.2
 @@ -28,7 +28,7 @@
  .\"     @(#)lseek.2	8.3 (Berkeley) 4/19/94
  .\" $FreeBSD$
  .\"
 -.Dd April 5, 2007
 +.Dd November 21, 2011
  .Dt LSEEK 2
  .Os
  .Sh NAME
 @@ -113,10 +113,9 @@ of the existing end-of-file of the file.
  If data is later written
  at this point, subsequent reads of the data in the gap return
  bytes of zeros (until data is actually written into the gap).
 -.Pp
 -Some devices are incapable of seeking.
 -The value of the pointer
 -associated with such a device is undefined.
 +However, the
 +.Fn lseek
 +system call does not, by itself, extend the size of a file.
  .Pp
  A
  .Qq hole
 @@ -197,13 +196,43 @@ is associated with a pipe, socket, or FIFO.
  The
  .Fn lseek
  system call is expected to conform to
 -.St -p1003.1-90 .
 +.St -p1003.1-2008 .
 +.Pp
 +The
 +.Dv SEEK_HOLE
 +and
 +.Dv SEEK_DATA
 +directives, along with the
 +.Er ENXIO
 +error, are extensions to that specification.
  .Sh HISTORY
  The
  .Fn lseek
  function appeared in
  .At v7 .
  .Sh BUGS
 +If the
 +.Fn lseek
 +system call is operating on a device which is incapable of seeking,
 +it will request the seek operation and return successfully,
 +even though no seek was performed.
 +Because the
 +.Ar offset
 +argument will be stored unconditionally in the file descriptor of that device,
 +there is no way to confirm if the seek operation succeeded or not
 +(e.g. using the
 +.Fn ftell
 +function).
 +Device types which are known to be incapable of seeking include
 +tape drives.
 +.Pp
 +The
 +.Fn lseek
 +system call will not detect whether media are present in changeable
 +media devices such as DVD or Blu-ray devices.
 +A requested seek operation will therefore return sucessfully when no
 +medium is present.
 +.Pp
  This document's use of
  .Fa whence
  is incorrect English, but is maintained for historical reasons.
 
 --fdj2RfSjLxBAspz7--
Responsible-Changed-From-To: freebsd-doc->eadler 
Responsible-Changed-By: eadler 
Responsible-Changed-When: Sun Mar 4 04:31:47 UTC 2012 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162765 
Responsible-Changed-From-To: eadler->freebsd-doc 
Responsible-Changed-By: eadler 
Responsible-Changed-When: Sun Sep 2 16:52:36 UTC 2012 
Responsible-Changed-Why:  
I won't be looking at this PR for a while and I need to clear some out 
of my queue 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162765 
>Unformatted:
