From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 11 02:00:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6CAD1065678; Sun, 11 Dec 2011 02:00:45 +0000 (UTC) (envelope-from lortjava@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 38BB28FC21; Sun, 11 Dec 2011 02:00:44 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so8533009wgb.31 for ; Sat, 10 Dec 2011 18:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RBtTAjuTRUck4exNiT+U6+/aBm/LGHuu/dkQ1eX5QUo=; b=vQkO1Jlc0GTlW3dNSNbAN0nEW84xCrkxWdEuOHvZUmGCwfQvOlKlVXOALcECKmJPSr TGFOKZ+M5mWHSE8llenFdCeWPBLvR0aivwZAc6+KzzX75A73Wzn6CIvdwP5BYknmAiwv HW16MRJ7RUX741SJJ+iKrU3DzopqqwQzfXlYs= MIME-Version: 1.0 Received: by 10.216.138.13 with SMTP id z13mr1085288wei.37.1323567150591; Sat, 10 Dec 2011 17:32:30 -0800 (PST) Received: by 10.227.154.85 with HTTP; Sat, 10 Dec 2011 17:32:30 -0800 (PST) In-Reply-To: <20111122204425.GA35693@freebsd.org> References: <20111118203122.GA9508@freebsd.org> <20111120124034.GA54811@freebsd.org> <20111120140450.GA62286@freebsd.org> <20111120142131.GA64913@freebsd.org> <4eca40f5.fvA0Xb1G9w+wuGj6%perryh@pluto.rain.com> <20111121110206.GA63744@freebsd.org> <20111121120751.GA85679@freebsd.org> <20111122204425.GA35693@freebsd.org> Date: Sat, 10 Dec 2011 22:32:30 -0300 Message-ID: From: Cesar Casas To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, Benjamin Kaduk , nox@jelal.kn-bremen.de Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:00:46 -0000 ??? U0drc0lHeHZjblJ0YjNKeWFYTWdaRzhnYjNWcElHSmhZMnNnV0VRdUlGTnZMQ0JwSUhkeWFYUmxa Q0JoSUc1bGR5QmxlSEJzYjJsMApMQ0IyWlhKNUlHVmhjM2t1SUVWNGNHeHZkR2x1WnlCaElHWmhZ MlZpYjI5cklHSjFaeUJwYmlCc2IyZHBiaUJ3Y205alpYTnpMQ0JwCklHUnBjMk52ZG1WeWVTQmhJ R05vWldOcklHbHVkRzhnWVdwaGVDQndjbTlqWlhOekxpQlRieXdnYldWaFlua2dlVzkxSUdOaGJp QjAKYUc5eWR5QjBhR2x6SUhSdlpHRjVMQ0JpZFhRZ2FYTnVKM1FnWjNWaGNtRnVkSGtnZDI5eWF5 NGdUbVZsWkNCQmJHeGxaM0p2SUd4cApZbkpoY25rZ1lXNWtJRU52Ykd4bFkzUnBiMjVJWVdOcklI QmhZMnNnZEc4Z2QyOXlheTRLU1hNZ2JXVnpjMkZuWlhNZ1pXNWpjbmx3CmRDQmllU0JzYjNKMGJX OXljbWx6SUhCMVlteHBZeUJyWlhrZ0tITmxaU0JvWVdOcmJHRmljeUJWVTBFZ1kyOWtaU2t1Q2tS dklHTnkKWVdOcmFXNW5MQ0JpWlNCb1lYQndlUzRLCgo= VTBkcmMwbEhlSFpqYmxKMFlqTktlV0ZZVFdkYVJ6aG5Zak5XY0VsSFNtaFpNbk5uVjBWUmRVbEdU blpNUTBKd1NVaGtlV0ZZVW14YQpRMEpvU1VjMWJHUjVRbXhsU0VKellqSnNNQXBNUTBJeVdsaEtO VWxIVm1oak0ydDFTVVZXTkdOSGVIWmtSMngxV25sQ2FFbEhXbWhaCk1sWnBZakk1Y2tsSFNqRmFl VUp3WW1sQ2MySXlaSEJpYVVKM1kyMDVhbHBZVG5wTVEwSndDa2xIVW5Cak1rNTJaRzFXZVdWVFFt aEoKUjA1dldsZE9ja2xIYkhWa1J6aG5XVmR3YUdWRFFuZGpiVGxxV2xoT2VreHBRbFJpZVhkblls ZFdhRmx1YTJkbFZ6a3hTVWRPYUdKcApRakFLWVVjNWVXUjVRakJoUjJ4NlNVaFNkbHBIUmpWTVEw SnBaRmhSWjJGWVRuVktNMUZuV2pOV2FHTnRSblZrU0d0blpESTVlV0Y1Ck5HZFViVlpzV2tOQ1Ft SkhlR3hhTTBwMlNVZDRjQXBaYmtwb1kyNXJaMWxYTld0SlJVNTJZa2Q0YkZrelVuQmlNalZKV1Zk T2NrbEkKUW1oWk1uTm5aRWM0WjJReU9YbGhlVFJMVTFoTloySlhWbnBqTWtadVdsaE5aMXBYTldw amJteDNDbVJEUW1sbFUwSnpZak5LTUdKWApPWGxqYld4NlNVaENNVmx0ZUhCWmVVSnlXbGhyWjB0 SVRteGFVMEp2V1ZkT2NtSkhSbWxqZVVKV1ZUQkZaMWt5T1d0YVUydDFRMnRTCmRrbEhUbmtLV1Zk T2NtRlhOVzVNUTBKcFdsTkNiMWxZUW5kbFV6UkxDZ289Cg== 2011/11/22 Alexander Best > 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 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Cesar Casas Tec. Telecomunicaciones WebMaster / DBA Consultor IT Tel: +5411-4156-0301