Bug#11922: marked as done (kernel produces no messages for a blank tape)

[owner@bugs.debian.org (Debian Bug Tracking System)]

Your message dated Thu, 7 Feb 2008 10:27:11 +0100
with message-id <20080207092711.GM5386@stro.at>
and subject line Bug#11922: I/O error on blank tapes
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---

• To: Debian bugs submission address <submit@bugs.debian.org>
• Subject: kernel produces no messages for a blank tape
• From: Ian Jackson <ian@davenant.greenend.org.uk>
• Date: Wed, 6 Aug 1997 20:53:47 +0100
• Message-id: <E0wwC9T-00027v-00@davenant.greenend.org.uk>

Package: kernel
Version: as on rescue disk 28/05/1997

If I insert a blank tape in my SCSI tape drive (an HP T4000s) and try
to read it there are no kernel messages telling me the nature of my
mistake, just the report `I/O error' from the program trying to access
the tape.

Ian.

--- End Message ---

--- Begin Message ---

• To: Kai Makisara <Kai.Makisara@kolumbus.fi>
• Cc: 11922-done@bugs.debian.org
• Subject: Re: Bug#11922: I/O error on blank tapes
• From: maximilian attems <max@stro.at>
• Date: Thu, 7 Feb 2008 10:27:11 +0100
• Message-id: <20080207092711.GM5386@stro.at>
• In-reply-to: <alpine.LSU.1.00.0802051846230.8573@kai.makisara.local>
• References: <20080204142206.GB5532@stro.at> <20080204212835.GA29286@gollum.tnic> <1202162213.3096.119.camel@localhost.localdomain> <alpine.LSU.1.00.0802051846230.8573@kai.makisara.local>

On Tue, 05 Feb 2008, Kai Makisara wrote:

> This is not a bug, it is a feature. There is _nothing_ on the tape and if 
> you try to read something, you get an error. The same thing applies to 
> reading after the last filemark. Note that after writing a filemark at the 
> beginning of the tape, the situation is different. Now there is a file and 
> the normal EOF semantics apply although there still is no data.
> 
> I admit that the error return could be more descriptive but the st driver 
> tries to be compatible with other Unices.
> 
> The behavior can be changed if Linux does not match other Unices. I don't 
> remember if I have tested just this with other Unices. I will try to test 
> this with Tru64 tomorrow. If anyone has data on other Unices, it would be 
> helpful.
> 
> -- 
> Kai

thanks a lot for your feedback!

closing the bug report with your information. haven't ever worked on
tapes so not experienced at all on that domain. happy to have learned
aboves.

-- 
maks

--- End Message ---