Along the same lines of the problem James discovered, I found a problem 
relating to holes in resized files.

This impacts all YAFFS versions (Linux, WinCE, direct...)

If one truncates a file then expands it again, then the expanded "holes" 
should be zeros.

However, all yaffs was doing for the partial page left at the end of the 
resize was just marking the number of valid bytes. Then, when the page got 
read back the old contets would be restored. It's a pretty wierd sequence...

YAFFS was not being fooled by the most common usage of truncation (truncation 
to zero length) or any other page-aligned truncations.

A simple one-liner in yaffs_ResizeFile fixes this, now in CVS.

See enclosed test case, but herewith  also a brief description:

After first write, file contents is "abcdefghijklmnopqrstuvwxyz".
After truncation file contents is "abc"
After second write file contents should be "abc\0\01", but with the bug was 
"abcde1".

-- CHarles