Re: Possible bug in file truncation code
David Woodhouse <[email protected]> Fri, 25 Feb 2005 17:59:40 +0000
| Newsgroups | gmane.linux.file-systems.jffs |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 2005-02-25 at 18:43 +0100, Andrew Lunn wrote: > >The test case does the open, followed by a close then umount and then >mounts. The mount then reports: > ><5>Eep. Child "TestFile.txt" (ino #10) of dir ino #1 doesn't exist! The inode #10 has no nodes at all, but it should have been left with one -- a metadata node, which contains uid, gid, size, etc. information but no data payload. This should have been written before calling jffs2_truncate_fraglist(). Remember that the actual obsoletion of nodes on the medium is just an optimisation, and it may not happen with NAND or other types of flash. Any truncation (to zero, or to any other length) should first write a new node with the appropriate i_size, before calling jffs2_truncate_fraglist(). If you support truncate-to-longer (Linux generally does but POSIX doesn't require it) then your new metadata node should also have a data payload make sure the space between the old EOF and the new EOF is filled with zeroes and prevent old data from before a previous truncation from 'showing through' where the file is now extended. Zeroes compress quite easily with JFFS2_COMPR_ZERO -- there's no actual payload on the medium at all. See jffs2_do_setattr() in fs.c for the Linux version -- in Linux, that function also handles changes to i_size. -- dwmw2 To unsubscribe from this list: send the line "unsubscribe jffs-dev" in the body of a message to [email protected]