Date: Tue, 22 Nov 2011 20:44:25 +0000 From: Alexander Best <arundel@freebsd.org> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, nox@jelal.kn-bremen.de Subject: Re: easy way to determine if a stream or fd is seekable Message-ID: <20111122204425.GA35693@freebsd.org> In-Reply-To: <alpine.GSO.1.10.1111212311530.882@multics.mit.edu> References: <20111118203122.GA9508@freebsd.org> <E693FAEB-1D8D-41A0-AEB7-3EB00419F432@kientzle.com> <20111120124034.GA54811@freebsd.org> <20111120140450.GA62286@freebsd.org> <20111120142131.GA64913@freebsd.org> <4eca40f5.fvA0Xb1G9w%2BwuGj6%perryh@pluto.rain.com> <alpine.GSO.1.10.1111210112050.882@multics.mit.edu> <20111121110206.GA63744@freebsd.org> <20111121120751.GA85679@freebsd.org> <alpine.GSO.1.10.1111212311530.882@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon Nov 21 11, Benjamin Kaduk wrote: > On Mon, 21 Nov 2011, Alexander Best wrote: > > >On Mon Nov 21 11, Alexander Best wrote: > >>On Mon Nov 21 11, Benjamin Kaduk wrote: > >>>On Mon, 21 Nov 2011, perryh@pluto.rain.com wrote: > >>> > >>>>Alexander Best <arundel@freebsd.org> wrote: > >>>> > >>>>>here's a revised patch. > >>>>>... > >>>>>+.Sh CAVEATS > >>>>>+If the > >>>>>+.Fn lseek > >>>>>+system call is operating on a device, which is incapable of seeking, > >>>>>+it will request the seek operation and complete successfully. > >>>> > >>>>I think it would be better without the first comma (after "device"). > >>> > >>>Definitely. > >>> > >>>Also, > >>> > >>>+.Sh CAVEATS > >>>+If the > >>>+.Fn lseek > >>>+system call is operating on a device, which is incapable of seeking, > >>>+it will request the seek operation and complete successfully. > >>> > >>>I would prefer something like "request the seek operation and return as > >>>if > >>>the seek was successful, even though no seek was performed." > >>> > >>>+The value of the pointer associated with such a device is undefined. > >>> > >>>"Which pointer?" That it is "the file offset" was clear from context > >>>where this line was moved from, but is no longer, here. > >>> > >>>+Device types which can be incapable of seeking include, > >>>+but are not limited to, tape drives. > >>> > >>>This is an awkward phrasing; perhaps just "Many tape drives are incapable > >>>of seeking and can trigger this bug."? > >> > >>this is too limited. this suggests that only certain tape drives won't > >>seek > >>after a successfull return of lseek(). as i mentioned beforehand, this is > >>also > >>the case with device with insertable media, such as dvd and blue-ray > >>drives. > >>here lseek() will sucessfully return, without a media inserted. > >> > >>i'll rephrase the whole patch and will submit a revised version. i think a > >>reference to POLA, would also be a good idea, as suggested by perry@ > > > >here's a revised patch. > > % diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2 > % index 874c523..bcd9d20 100644 > % --- a/lib/libc/sys/lseek.2 > % +++ b/lib/libc/sys/lseek.2 > % @@ -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 in the file descriptor of that device, > > This sentence assumes more familiarity with file i/o implementation than > seems prudent. Perhaps "stored in the file descriptor of that device and > thus used for future queries" or something similar? > > % +there is no way to verifying/falsify the seek operation afterwards > > "verifying" is incorrect, here. Just "verify" would work, but the combo > "verify/falsify" doesn't feel quite right. > I guess I want "no way to confirm success of the seek operation" (no > 'afterwards'). > > % +(e.g. using the > % +.Fn ftell > % +function). > % +Device types which are known to be incapable of seeking include > % +tape drives. > > "most"? I think someone said that certain (old) drives could actually > seek under some circumstances. > > % +.Pp > % +The > % +.Fn lseek > % +system call will not detect, whether media are present in changeable > % +media devices, such as DVD or Blue-ray devices. > > The first comma is bogus; the second comma could be removed, and probably > should be. > Also, "Blu-ray" has no 'e' (but apparently is capitalized in that way). > > % +A requested seek operation will therefore return sucessfully in case > % +of an uninserted medium. > > s/in case of an uninserted medium/when no medium is present/. > > Thanks for the fixups, thanks for your suggestions. i included some of them into the patch and also added a few stuff myself. maybe you could have a look at the problem report i submitted [1] and post a followup mail, what you think. this worked quite well the last time, in case of the du(1) man page patch, imo. ;) cheers. alex [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162765 > > Ben > > > % +.Pp > % This document's use of > % .Fa whence > % is incorrect English, but is maintained for historical reasons.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111122204425.GA35693>