From owner-freebsd-current  Mon Nov 20 14:15:44 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id OAA14996
          for current-outgoing; Mon, 20 Nov 1995 14:15:44 -0800
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14982
          ; Mon, 20 Nov 1995 14:15:38 -0800
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02255; Mon, 20 Nov 1995 15:14:22 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199511202214.PAA02255@phaeton.artisoft.com>
Subject: ffs_truncate problem?
To: hackers@freebsd.org, current@freebsd.org
Date: Mon, 20 Nov 1995 15:14:22 -0700 (MST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1040      
Sender: owner-current@freebsd.org
Precedence: bulk

In /sys/ufs/ffs/ffs_inode.c in ffs_truncate():


	oip->i_flag |= IN_CHANGE | IN_UPDATE;
	error = VOP_UPDATE(ovp, &tv, &tv, 1);
	if (error)
		allerror = error;
	/*
	 * Having written the new inode to disk, save its new configuration
	 * and put back the old block pointers long enough to process them.
	 * Note that we save the new block configuration so we can check it
	 * when we are done.
	 */
	bcopy((caddr_t)&oip->i_db[0], (caddr_t)newblks, sizeof newblks);
	bcopy((caddr_t)oldblks, (caddr_t)&oip->i_db[0], sizeof oldblks);
	oip->i_size = osize;
	vflags = ((length > 0) ? V_SAVE : 0) | V_SAVEMETA;
	allerror = vinvalbuf(ovp, vflags, ap->a_cred, ap->a_p, 0, 0);

When truncating a file short.

Does is strike anyone as odd that the code keeps going if the VOP_UPDATE
fails?

This *might* explain the read-only NFS mount file truncation.  Basically
the error (if any) from VOP_UPDATE() is ignored.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.