Re: easy way to determine if a stream or fd is seekable

[Alexander Best]

On Wed Nov 16 11, Alexander Best wrote:
> On Tue Nov 15 11, Brandon Gooch wrote:
> > On Nov 15, 2011 2:25 PM, "Alexander Best" <aru...@freebsd.org> wrote:
> > >
> > > hi there,
> > >
> > > one of the things i'm missing is an easy way to determine, whether a
> > stream or
> > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are
> > > performing so much stuff just to find out if this is the case, and they
> > still
> > > are doing a very poor job.
> > >
> > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the
> > result:
> > >
> > > `dd if=/dev/zero bs=1m count=1 skip=100000`:
> > >
> > > on freebsd:
> > > 57,41 real 0,05 user 43,21 sys
> > >
> > > on openbsd:
> > > 0,88 real 0,00 user 0,07 sys
> > >
> > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is:
> > >
> > > there doesn't seem to exist a unified way of checking seekable == TRUE. so
> > > every userspace application seems to do it differently and most of them
> > (dd(1)
> > > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only
> > regular
> > > files are seekable. this means that hd(1) fired at /dev/ada* with a high
> > skip
> > > value takes ages! dd(1) is a bit smarter in this case, but still not
> > correct.
> > >
> > > idealy there would be something like stat.st_mode (see stat(2)) where one
> > > could simply do a S_ISSEEK(m). so far the best and easiest solution i've
> > seen
> > > is:
> > >
> > > fd = open(argv[1], O_RDONLY);
> > > if (fd == -1)
> > > exit(1);
> > > if (lseek(fd, 0, SEEK_CUR) != -1)
> > > printf ("%d is seekable.\n", fd);
> > > else
> > > printf ("%d is not seekable.\n", fd);
> > >
> > > seeing an application iterate through a stream or fd via getchar(),
> > although
> > > a simple seek() would work is very frustrating. i think what would be
> > needed
> > > is a simple function or macro that userspace applications can make use of.
> > > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd,
> > > solaris or plan9?
> > >
> > > cheers.
> > > alex
> > >
> > > references:
> > > [1]
> > http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes
> > > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485
> > > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485
> >
> > So, according to APUE 2nd Edition, seek should be supported on anything
> > that's not a pipe, FIFO, or socket. In fact, the "test for seekability"
> > you've provided above closely resembles the example given in that text.
>
> if this really is the case, things could even be easier in a freebsd specific
> manor than the code above:
>
> !S_ISFIFO(m) && !S_ISSOCK(m)
>
> this means it would be trivial to write a new macro S_ISSEEK which would test
> stat.st_mode against the according bits.

here's a patch, which also fixes a comment.

cheers.
alex

>
> cheers.
> alex
>
> >
> > Need to think about this more before commenting further...
> >
> > -Brandon

[Alexander Best]

> hmmm...the patch doesn't seem to work for directories and symbolic links
> unfortunately. does anybody spot the problem?
>
> i've attached two testing applications. mode.c will do the tests via the S_IS*
> macros and requires the patch i've posted beforehand to stat.h. the other
> application is seekable.c, which will use lseek(2) to test, whether a file
> argument is seekable or not. basically both applications should report the
> same!

grrrr...the attachments got scrubbed!

>
> cheers.

>
> >
> > cheers.
> > alex
> >
> > >
> > > cheers.
> > > alex
> > >
> > > >
> > > > Need to think about this more before commenting further...
> > > >
> > > > -Brandon
>

> > diff --git a/sys/sys/stat.h b/sys/sys/stat.h
> > index 1b03bd2..ab5ae44 100644
> > --- a/sys/sys/stat.h
> > +++ b/sys/sys/stat.h
> > @@ -238,10 +238,11 @@ struct nstat {
> > #define S_ISCHR(m) (((m) & 0170000) == 0020000) /* char special */
> > #define S_ISBLK(m) (((m) & 0170000) == 0060000) /* block special */
> > #define S_ISREG(m) (((m) & 0170000) == 0100000) /* regular file */
> > -#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* fifo or socket */
> > +#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* pipe or fifo */
> > #if __POSIX_VISIBLE >= 200112
> > #define S_ISLNK(m) (((m) & 0170000) == 0120000) /* symbolic link */
> > #define S_ISSOCK(m) (((m) & 0170000) == 0140000) /* socket */
> > +#define S_ISSEEK(m) (((m) & 0150000) == 0) /* seekable file */
> > #endif
> > #if __BSD_VISIBLE
> > #define S_ISWHT(m) (((m) & 0170000) == 0160000) /* whiteout */
>

[Alexander Best]

> hmmm...the patch doesn't seem to work for directories and symbolic links
> unfortunately. does anybody spot the problem?

here's an updated patch, which should work.

cheers.
alex

>
> i've attached two testing applications. mode.c will do the tests via the S_IS*
> macros and requires the patch i've posted beforehand to stat.h. the other
> application is seekable.c, which will use lseek(2) to test, whether a file
> argument is seekable or not. basically both applications should report the
> same!
>

> cheers.

>
> >
> > cheers.
> > alex
> >
> > >
> > > cheers.
> > > alex
> > >
> > > >
> > > > Need to think about this more before commenting further...
> > > >
> > > > -Brandon
>

[Joerg Sonnenberger]

On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote:
> On Wed Nov 16 11, Joerg Sonnenberger wrote:

> > On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote:
> > > one of the things i'm missing is an easy way to determine, whether a stream or
> > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are
> > > performing so much stuff just to find out if this is the case, and they still
> > > are doing a very poor job.
> >

> > Isn't the primary issue that FreeBSD doesn't properly report errors for
> > lseek(2)? I think you should start from that and not hack around the
> > fallout...
>
> what do you mean? lseek(2) returns -1, when the file descriptor is not
> seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...)
> and it always returned the correct result.

If that were the case, you wouldn't need your flag to detect seek
support. But e.g. some devices silently ignore seek requests without
reporting errors. At least that is what I remember from the last time
this has brought up.

Joerg
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Alexander Best]

On Thu Nov 17 11, Joerg Sonnenberger wrote:
> On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote:
> > On Wed Nov 16 11, Joerg Sonnenberger wrote:
> > > On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote:
> > > > one of the things i'm missing is an easy way to determine, whether a stream or
> > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are
> > > > performing so much stuff just to find out if this is the case, and they still
> > > > are doing a very poor job.
> > >
> > > Isn't the primary issue that FreeBSD doesn't properly report errors for
> > > lseek(2)? I think you should start from that and not hack around the
> > > fallout...
> >
> > what do you mean? lseek(2) returns -1, when the file descriptor is not
> > seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...)
> > and it always returned the correct result.
>
> If that were the case, you wouldn't need your flag to detect seek
> support. But e.g. some devices silently ignore seek requests without
> reporting errors. At least that is what I remember from the last time
> this has brought up.

this is the first time i hear about problems with seek requests. would be nice
to see some examples cases. was this discussed on the mailinglists? or
submitted as a problem report?

even if lseek(2) would always work, it would be overhead. there's no need to
test a file operand against seeking, because we can derive that from its type.
a file operand that isn't a pipe, fifo or socket IS seekable. i consider
running S_ISSEEK(m) much more intuitive than first opening a file, saving its
filedescriptor, dealing with errors, running lseek(2) with a zero offset
argument (which appears to be very hackish), dealing with lseek(2) errors and
finally evaluating lseek(2)'s return value.

also the way of checking, whether a file operand is seekable via lseek(2) as
always existed and people don't seem to understood that. hexdump(1) and dd(1)
weren't written by amateurs -- still they aren't using lseek(2) on their file
operand or aren't doing it correctly. so i believe developers should be given a
more intuitive way to check for the ability to seek on a given file operand.

S_ISSEEK(m) seems to be a very good solution from my point of view.

cheers.
alex

[Alexander Best]

On Thu Nov 17 11, Dieter BSD wrote:
> > lseek() on a tape drive does not return an error, nor does it
> > actually do anything.
>
> IIRC some tape drives can seek, while others cannot.
> Vague memories that it is supposed to be possible to put a
> filesystem on a DECtape and mount the filesystem.

i took a look at the bsdtar sources and before the lseek() a function called
test_for_append() is run. apart from other things it will do the following:

if (!S_ISREG(s.st_mode) && !S_ISBLK(s.st_mode))
lafe_errc(1, 0,
"Cannot append to %s: not a regular file.",
bsdtar->filename);

but again this is too restrictive. take a look at /dev/zero e.g.:

otaku% ./mode /dev/zero
Block special file: 0
Character special file: 1
Directory: 0
Pipe or FIFO special file: 0
Symbolic link: 0
Regular file: 0
Socket: 0
Whiteout: 0
Seekable: 1

it is not regular file and no block special file, so bsdtar will bail out
for no reason!

i think there are two possibilities:

1) add code to lseek() that will return -1 for all tape drives.
2) deal with those tape drives that don't support seeking individually.

identifying a tape drive is easy. here's dd's code snippet:

if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) {
if (ioctl(io->fd, FIODTYPE, &type) == -1)
err(1, "%s", io->name);

if (type & D_TAPE)
io->flags |= ISTAPE;
}

this could be added to lseek() and when "type & D_TAPE" == TRUE, then we could
return -1. this would be method 1). no idea how to fix this issue using method
2) though. probably driving into the driver code of the according tape drives.

cheers.
alex

ps: thanks to nox@ for pointing me to the initial thread, where this issue was
discussed [1]. however the purpose of that thread was mainly fixing
libarchive/bsdtar and not so much really fixing the issue at hand.

also i'll consider re-opening problem report [2], wince this was never really
fixed.

[1] http://markmail.org/message/n6tp5dbv7sbzzujc
[2] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313

>
> It might be that FreeBSD doesn't currently support seeking
> on a tape, but we shouldn't paint ourselves into a corner
> by assuming that it is fundimentally impossible.

[David Brodbeck]

On Fri, Nov 18, 2011 at 4:13 AM, Stefan Esser <s...@freebsd.org> wrote:

> I have no idea, whether tape drives are still in wide use. For the
> purposes that I administrated and used tapes for (gamma/particle
> coincidence spectroscopy and large numerical simulations), large disk
> arrays have completely replaced tape storage. Disk drives are cheaper
> than tape cartridges, today ...
>
>
>From what I've seen, tape for *backup* is mostly going away; disk-to-disk
backup is as cheap or cheaper and much faster. Tape for *archival*,
however, is still alive and well; when you have many petabytes of data that
you're required to keep in storage forever, but may or may not ever need to
read again, tape still looks more attractive. In big installations the
tape drives are often buffered by disk arrays to minimize backup time and
allow the tape drives to stream more effectively.

You also still see tape used a lot for offsite backups, although as
Internet speeds have gone up more and more of that is happening by sending
bits across the network instead of tapes over the highway. The bandwidth
of the proverbial station wagon full of tapes is no longer quite as
impressive as it used to be. ;)

--
David Brodbeck
System Administrator, Linguistics
University of Washington

[Alexander Best]

On Fri Nov 18 11, Alexander Best wrote:
> On Fri Nov 18 11, Tim Kientzle wrote:

> > On Nov 17, 2011, at 1:48 PM, Alexander Best wrote:
> >
> > > On Thu Nov 17 11, Dieter BSD wrote:
> > >>> lseek() on a tape drive does not return an error, nor does it
> > >>> actually do anything.
> > >>
> > >> IIRC some tape drives can seek, while others cannot.
> > >> Vague memories that it is supposed to be possible to put a
> > >> filesystem on a DECtape and mount the filesystem.
> > >

> > > or how about the following:
> > >
> > > 1) if the file argument we're seeking on is a tape drive, just do a regular
> > > seek operation.
> > > 2) afterwards use ftell() to verify that the seek REALLY happend. if it didn't,
> > > return -1 and set errno = EBADF.
> >
> > ftell() can't tell whether the seek really happened or not.
> > All it can do is ask the kernel, and the kernel doesn't know.
> >
> > Here is my current understanding:
> >
> > When you call lseek(), the kernel just stores the requested
> > offset in the file descriptor. lseek() always succeeds because
> > storing the requested offset in the file descriptor always succeeds.
> > (Except that the kernel specially checks if the file descriptor
> > is a pipe.)
> >
> > ftell() just obtains the data from the file descriptor.
> > So it always succeeds and always returns the data from
> > the previous seek request, regardless of whether that seek
> > actually did anything.
> >
> > With the next read or write request, the device driver may inspect the
> > offset information in the file descriptor. Or it can ignore
> > it. Almost all tape device drivers ignore it. Filesystems
> > uniformly support it. Disk drivers uniformly support it.
> > Other drivers vary considerably.
> >
> > In short: No, there is no "easy way" to determine if an
> > arbitrary stream or fd is seekable. If you try to create
> > a function that determines this, be certain to include
> > "Don't Know" as a possible return value.
>
> well it really depends what the goal is. it appears fixing fseek() for all
> cases is impossible then. however from a pragmatic point of view:
>
> why does a user have to wait for a command such as hd(1) or dd(1) working on
> files such as /dev/zero, /dev/null, /dev/(u)random or even /dev/ada* (only
> hd(1) -- dd(1) supports seeking here) for ages, although it could suceed in
> less than a second?
>
> the fact is: users care for speed and freebsd is slower than linux and openbsd
> in these cases. users aren't interested in the fact that lseek() won't work
> with tapes. most of them have probably never seen one (me included).
>
> if we return an error from within lseek() whenever lseek() was fired at a tape
> drive, wouldn't that cover 99% of all the possible cases?

something like the following inside lseek() would take care of tape drives:

if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) {
if (ioctl(io->fd, FIODTYPE, &type) == -1)
err(1, "%s", io->name);

if (type & D_TAPE)

return(EBADF)
}

cheers.
alex

>
> cheers.
> alex
>
> >
> > Tim

[Juergen Lock]

On Fri, Nov 18, 2011 at 12:00:07PM -0800, Tim Kientzle wrote:
>
> On Nov 17, 2011, at 12:55 PM, Juergen Lock wrote:
>
> >>
> >> After a few experiments, bsdtar stopped using lseek() on
> >> FreeBSD for anything other than regular files and block
> >> devices. I believe there are other things that do support
> >> seeking, but I don't believe there is an accurate mechanism
> >> for determining whether lseek() is correctly supported.
> >
> > Ah is that the reason why my patch never made it into FreeBSD 9?
> > I'm talking about this thread, where I also commented on seeking
> > on tape:
> >
> > http://docs.freebsd.org/cgi/mid.cgi?20100220101724.GA26604
> > (Re: "tar tfv /dev/cd0" speedup patch)
> >
> > entire thread here:
> > http://markmail.org/message/nfznipqik3tuhbqp
> >
> > Cheers,
> > Juergen (who would still like to see a faster "tar tfv /dev/cd0"... :)
>
> I would like to see that as well.
>
> Take a look at
>
> http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c
>
> Especially the comments about detecting "disk-like" devices.
> I rewrote a bunch of this code to introduce an explicit
> notion of "strategy" so that we could optimize access
> to a variety of different devices.
>
> This code has a notion of "disk-like" file descriptors and
> some optimizations for such. There are some comments
> in there outlining similar optimizations that could be made
> for "tape-like" or "socket-like" devices.

Ah so it's `just' a slow release cycle?

% grep DIOCGMEDIASIZE /home/ncvs/src/lib/libarchive/archive_read_open_filename.c,v
%

When will we see this code in FreeBSD? 10.0? 9.1? 8.3? :)

Curious...
Juergen

[Tim Kientzle]

On Nov 18, 2011, at 2:10 PM, Juergen Lock wrote:

> On Fri, Nov 18, 2011 at 12:00:07PM -0800, Tim Kientzle wrote:
>>
>> On Nov 17, 2011, at 12:55 PM, Juergen Lock wrote:
>>
>>>>
>>>> After a few experiments, bsdtar stopped using lseek() on
>>>> FreeBSD for anything other than regular files and block
>>>> devices.
>>>

>>> Ah is that the reason why my patch never made it into FreeBSD 9?

>>> ….

>>> Cheers,
>>> Juergen (who would still like to see a faster "tar tfv /dev/cd0"... :)
>>
>> I would like to see that as well.
>>
>> Take a look at
>>
>> http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c
>>
>

> Ah so it's `just' a slow release cycle?
>
> % grep DIOCGMEDIASIZE /home/ncvs/src/lib/libarchive/archive_read_open_filename.c,v
> %
>
> When will we see this code in FreeBSD? 10.0? 9.1? 8.3? :)

Definitely in FreeBSD 10.

Unfortunately libarchive 3.0 breaks the API and ABI, so it can't
be imported into 9.1 or 8.3 wholesale. It should
be possible to back port select pieces, though.

Tim

[Alexander Best]

On Sat Nov 19 11, Tim Kientzle wrote:

>
> On Nov 18, 2011, at 12:31 PM, Alexander Best wrote:
>
> > On Fri Nov 18 11, Tim Kientzle wrote:
> >>

> >> Take a look at
> >>
> >> http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c
> >>

> >> Especially the comments about detecting "disk-like" devices.
> >> I rewrote a bunch of this code to introduce an explicit
> >> notion of "strategy" so that we could optimize access
> >> to a variety of different devices.
> >>
> >> This code has a notion of "disk-like" file descriptors and
> >> some optimizations for such. There are some comments
> >> in there outlining similar optimizations that could be made
> >> for "tape-like" or "socket-like" devices.
> >

> > great you posted that file as reference. i believe most of the stuff done there
> > should actually be done within lseek().
>
> Libarchive runs on a lot of systems other than FreeBSD.
> FreeBSD is not the only Unix-like system with this issue,
> so that code isn't going to go out of libarchive regardless.
>
> If you think those same ideas can be used in dd or hd
> to speed them up, please send your patches.

i'm on it. ;) i'll send in the patches in a few days.

>
> The key point: You cannot unconditionally call lseek()
> to skip over data. Instead, treat lseek() as an optimization
> that can be used under some circumstances. The
> question then becomes one of figuring out when
> that optimization can be enabled.

...however more importantly imo is that we fix the lseek(2) man page. i'm
adding a CAVEATS section, which includes some wording from the POSIX
definition, regarding the fact that lseek()'s behavior on devices that don't
support seeking is undefined or better: one cannot expect lseek() to return
an error, if the underlying device doesn't support seeking.

cheers.
alex

>
> Tim

[Dieter BSD]

> something like the following inside lseek() would take care of tape drives:
>
>        if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) {
>                if (ioctl(io->fd, FIODTYPE, &type) == -1)
>                        err(1, "%s", io->name);
>
>                if (type & D_TAPE)
>                        return(EBADF)
>        }

I'd suggest ENODEV ("Operation not supported by device") rather than
EBADF ("Bad file descriptor").

To do this correctly, we'd need some standard way to ask the
device driver if the device can perform the seek or not.

[Alexander Best]

On Sun Nov 20 11, Dieter BSD wrote:
> > something like the following inside lseek() would take care of tape drives:
> >
> >        if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) {
> >                if (ioctl(io->fd, FIODTYPE, &type) == -1)
> >                        err(1, "%s", io->name);
> >
> >                if (type & D_TAPE)
> >                        return(EBADF)
> >        }
>
> I'd suggest ENODEV ("Operation not supported by device") rather than
> EBADF ("Bad file descriptor").
>
> To do this correctly, we'd need some standard way to ask the
> device driver if the device can perform the seek or not.

this might be a bit of a problem, since those devices and drivers that don't
support seeking are mostly legacy tape drives. i don't think these drivers
are actively being maintained atm.

another issue are removable media. running the patched version of hexdump
(i posted a patch earlier today) shows that running fseeko() against /dev/cd0,
where no media is present, succeeds. with a media inserted however, /dev/cd0 is
very well capable of seeking.

cheers.
alex

[per...@pluto.rain.com]

Alexander Best <aru...@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").

IMO the whole section should be added to BUGS rather than creating
a new CAVEATS section. Returning "success" when the requested
operation actually _failed_ is a serious POLA violation.

[Benjamin Kaduk]

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, per...@pluto.rain.com wrote:
>>>
>>>> Alexander Best <aru...@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,

Ben


% +.Pp
% This document's use of
% .Fa whence
% is incorrect English, but is maintained for historical reasons.

[Cesar Casas]

???
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 <aru...@freebsd.org>

> 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...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>

--
Cesar Casas
Tec. Telecomunicaciones
WebMaster / DBA
Consultor IT

Tel: +5411-4156-0301