From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

From: Christoph Hellwig <hch@lst.de>

There's two callers:

 - the truncate path via notify_change, ->setattr, vmtruncate.  We
   already check for permissions here at the upper level
 - fat_delete_inode.  This one looks bogus to me - even if we delete
   an read-only or immutable inode we want to free the space allocated
   by it, else you leak disk blocks.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/fs/fat/file.c |    6 ------
 1 files changed, 6 deletions(-)

diff -puN fs/fat/file.c~remove-read-only-immutable-checks-from-fat_truncate fs/fat/file.c
--- 25/fs/fat/file.c~remove-read-only-immutable-checks-from-fat_truncate	Wed Aug 18 17:34:14 2004
+++ 25-akpm/fs/fat/file.c	Wed Aug 18 17:34:14 2004
@@ -90,12 +90,6 @@ void fat_truncate(struct inode *inode)
 	const unsigned int cluster_size = sbi->cluster_size;
 	int nr_clusters;
 
-	/* Why no return value?  Surely the disk could fail... */
-	if (IS_RDONLY (inode))
-		return /* -EPERM */;
-	if (IS_IMMUTABLE(inode))
-		return /* -EPERM */;
-
 	/* 
 	 * This protects against truncating a file bigger than it was then
 	 * trying to write into the hole.
_