Re: [9fans] seeking for the truth

[Dave Lukes <davel@anvil.com>]

Definite plus vote from me.
Nugatory seeks have annoyed me ever since 6th Ed.

Also,
if anything out there _is_ seek()ing without checking the result,
then either it's broke anyway,
or it knows it can safely ignore the result.
So, off the top of my head, I don't see compatibility as an issue.

Obviously this would need some more looking at,
and a pile of "grep seek ..."s, but it sounds like a plan to me ...

	Dave.

On Thu, 2004-02-12 at 16:16, rog@vitanuova.com wrote:
> i was caught up short just now when i tried to reverse
> some lines in acme by selecting them and executing "|tail -r".
>
> it didn't work.
> the reason?
>
> /sys/src/cmd/tail.c:94: 	seekable = seek(file,0L,0) == 0;
>
> the seek() is succeeding, even though standard input
> isn't actually seekable.
>
> the trouble is, it can't do anything else.
>
> we don't see this problem much because of the special case hack for
> "#|" in sseek(), but the tail code is a common hack, and an insidious
> one.  there are loads of special files around that don't allow
> seeking, and many programs that require files that are seekable (diff
> being the age-old example).
>
> surely a better solution is possible?  in general, a fileserver knows
> whether its files are seekable or not, because it determines how to
> interpret the seek offset.
>
> why not add a new bit to the file attributes, say DMNOSEEK (and
> associated QTNOSEEK)?  if set, it would indicate that file offsets
> when reading and writing the file will be ignored.  0x2 seems to be
> available.
>
> then the above line from tail.c could work, and finally it would be
> possible to write programs that know definitively whether they are
> able to seek on a particular file or not, rather than failing
> strangely sometime later.
>
> the amount of code involved would be tiny, and as far as i can see
> it would be completely backwardly compatible.
>
> thoughts?
>