From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu From: rog@vitanuova.com In-Reply-To: <7264eca72458d500639cb8fcb8c4ca79@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] seeking for the truth Date: Thu, 12 Feb 2004 16:16:39 +0000 Topicbox-Message-UUID: dfd4da82-eacc-11e9-9e20-41e7f4b1d025 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?