On Mon, 15 Nov 1999, Rodney W. Grimes wrote:
> >
> > Reread/reresponse, sorry- ENOCOFFEE:
> >
> >
> > > >
> > > > 1 filemark can not be used for EOT, it is EOF, you can't tell if what you
> > > > read next is another file or not that may have been left by a previosly
> > > > longer usage on the tape.
> > > >
> >
> >
> > Well, read until *BLANK CHECK* seems to be what the driver can and should
> > do. Let me ponder this some- I believe what I propose actually works fine
> > for all the devices we currently support (hell, I use it all the time
> > myself). If you can provide an actual example of a SCSI tape device that
> > if you take FreeBSD-current or FreeBSD-3.3 and do a 'mt seteotmodel 1' on
> > and *not* be able to detect EOT, let me know!
>
> You won't get ``blank check'' if the tape has previosly been written
> past where you just finished writing. Instead you often get trash.
Sorry, no. When you write a tape with these devices there's always a
leading erased area. That's why if you overwrite the front a tape you
can't skip past this area to recover data you really need. A misfeature of
modern technology.
>
> In your other message you talk about the driver getting 2 residuals
> in a row, well, unless you write the 2 EOF's you won't always get that...
> depends on if the tape drive does it automagically (which many newer
> drives do, they write 2 eof's and backspace over 1 of them for you when
> ever you tell them to write EOF, the drive itself uses 2 EOF's to
> determine logical EOT :-)).
I repeat what I said in other mail- can you actually show me a tape drive
where what I propose really doesn't work?
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
