Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!princeton!udel!mmdf
From: Leisner.Henr@xerox.com (Marty)
Newsgroups: comp.os.minix
Subject: bug reading block special defices?
Message-ID: <561@louie.udel.EDU>
Date: Mon, 5-Oct-87 17:19:35 EDT
Article-I.D.: louie.561
Posted: Mon Oct  5 17:19:35 1987
Date-Received: Thu, 8-Oct-87 05:44:38 EDT
Sender: mmdf@udel.EDU
Lines: 46


I was having a problem running mkfs on some hard disk partitions.  I'm
running 1.2 (I hope) using Aztec C.

I removed the sorting out of the winchester driver -- I found this
confusing and I'm not sure it was working right (I'm compiling using
Aztec C).  Anyway, I wanted the hdx partitions to agree with what
diskpart displays.

I had debug printfs in the winchester driver so I knew whenever it got
messages, what the message was and what it returned.

My question is:

For the inode of a block special device where (or does) rip->i_size of
the inode get initialized (where rip is a pointer to the inode)?  Is in
in the inode on disk (how does it know how big a block special file
is?)?

What was happening in mkfs is the write at the end of the file system
worked ok, the seeks worked okay, but the read returned 0, indicating
end of file.

In read.c, subroutine read_write, I notice the follwing:

		if (rw_flag == READING) {
			if ((bytes_left = f_size - position) <= 0)
				break;
			else
				if (chunk > bytes_left) chunk = bytes_left;
		}

Since f_size is initialized to rip->i_size, this comparison will just
terminate if bytes_left < 0 without issuing a request to the device
driver (which appears to be what is happening).  

Strange....


marty
ARPA:	leisner.henr@xerox.com
GV:  leisner.henr
NS:  martin leisner:henr801c:xerox
UUCP: martyl@rocksvax.uucp