Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Dec 1997 12:00:02 -0700 (MST)
From:      gibbs@narnia.plutotech.com (Justin T. Gibbs)
To:        Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc:        scsi@FreeBSD.org
Subject:   Re: Questions about mt and SCSI subsystem
Message-ID:  <199712111900.MAA00518@narnia.plutotech.com>
In-Reply-To: <19971211101003.17782@uriah.heep.sax.de>
References:  <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> <19971211005904.40551@uriah.heep.sax.de> <199712110327.UAA17646@narnia.plutotech.com> <19971211101003.17782@uriah.heep.sax.de>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <19971211101003.17782@uriah.heep.sax.de>,
	J Wunsch <j@uriah.heep.sax.de> writes:
> As Justin T. Gibbs wrote:
> 
>> > The correct behaviour is that any read or write attempt, upon
>> > encountering EOF (read) or EOM (write) should return a `short'
>> > read/write (i.e., set b_resid accordingly), but shall not flag an
>> > error condition.
>> 
>> Are you sure about the behavior for write?
> 
> Yep.  dump and multivolume tar rely on this behaviour, that's why dump
> -a is currently broken.  (*) It gets an EIO at the end of the tape,
> and assumes something went wrong with writing the last block, so
> instead of asking for the next tape (which it would have done upon
> write() returning 0), it asks to replace the same tape again, and
> wants to write this one once more.  Note that, while dump -a is my
> invention, the algorithm to detect the end of tape has been there all
> the time; dump -a only enforces the use of this algorithm over some
> tape length calculations.

It shouldn't return ENOSPC?  This error code is documented in write.2.
I agree that EIO is incorrect.

-- 
Justin T. Gibbs
===========================================
  FreeBSD - Turning PCs into workstations
===========================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712111900.MAA00518>