From: OGAWA Hirofumi From: Christoph Hellwig 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 Signed-off-by: Andrew Morton --- 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. _