On Mon, 2 Aug 1999, Marc SCHAEFER wrote:
>
>
> On Mon, 2 Aug 1999, Kai Makisara wrote:
>
> > The Linux SCSI tape driver does not support lseek() (and I have not seen
> > it on any other Unix either). The basic reason is that the data on a tape
> > is addressed as blocks and so lseek() does not make sense.
>
> So, why isn't fseek() failing with an error (I haven't tried seek()) ?
>
lseek() on tape does not make much sense but it does what it should do: it
advances the file pointer. However, the read returns the next block(s)
from the tape. (This is explicitly said on the man pages of some Unices; I
should add this to the Linux st man page.)
It is not clear to me whether the st driver should implement its own
llseek() that returns ESPIPE or use the default as it does now. The man
pages of the Unices I have access to say very little about this. The only
reference is found from the Digital Unix man page where they recommend
using lseek(fd, 0, SEEK_SET) to prevent overflow of the file pointer.
(Every read and write increment the file pointer. Some systems return an
error if the pointer is about to overflow. I have been bitten by that:
years ago I wondered why I can't read a tape file longer than 2 GB with an
Ultrix system. The Linux st driver does increment the file pointer but
overflow is not checked. This means that you can read and write as long
files as you wish but you should not trust the file pointer after 2 GB.
Note that you can get the number of bytes read/written with lseek(fd, 0,
SEEK_CUR). So, lseek() for tapes is not completely useless ;-)
I am willing to change the lseek() behaviour of the st driver if someone
gives me a strong enough reason. However, note that relying on the
behaviour of lseek() with tapes in general is bad because the behaviour
may not be consistent across Unix and Unix-like systems.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
