[Yaffs-archive] YAFFS: another "hole" bug fixed.

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

#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>

void main(void)
{
    int a;
    int r;
    int i;
    int l;

    

    char y[10];

    

    unlink("trunctest");

    

    a = open("trunctest", O_CREAT | O_TRUNC | O_RDWR,  S_IREAD | S_IWRITE);

    

    write(a,"abcdefghijklmnopqrstuvwzyz",26);

    

    ftruncate(a,3);
    l= lseek(a,0,SEEK_END);

    

    printf("truncated length is %d\n",l);

    

    lseek(a,5,SEEK_SET);
    write(a,"1",1);

    

    lseek(a,0,SEEK_SET);

    

    r = read(a,y,10);

    

    printf("read %d bytes:",r);

    

    for(i = 0; i < r; i++) printf("[%02X]",y[i]);

    

    printf("\n");

    
    
}