truncate() is broken for FAT

[snob-wolpike]

Steps to reproduce:

• Under RTEMS truncate existing file to zero length.
• Run chkdsk under any other OS (Linux, MacOSX, Win):

$ sudo fsck_msdos /dev/rdisk3s1
** /dev/rdisk3s1
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
/testwrite starts with free cluster
Truncate? [yn] n
/testwrite: Cluster chain starting at 3030 ends with cluster marked free
Truncate? [yn] n
/testwrite has too many clusters allocated (logical=0, physical=2048)
Drop superfluous clusters? [yn] n

Sample test code:

    FILE* f = fopen(TEST_FILENAME, "wb");
    if(f == 0)
    {
        printk("fopen() failed: %i %s\n", errno, strerror(errno));
        exit(0);
    }
    for(int i = 0; i < 256 * 1024; i += 1)
        fprintf(f, "Test message buffer bum %i\n", i);
    fflush(f);
    fclose(f);
    fflush(NULL);
    if(truncate(TEST_FILENAME, 0) != 0)
    {
        printk("truncate() failed: %i %s\n", errno, strerror(errno));
        exit(0);
    }

Both 4.11 and 4.12 affected

[snob-wolpike]

Technically O_TRUNC, ftruncate(), etc --- are broken as well.

[Chris Johns]

Have you flushed newlib's buffers and the block cache?

[snob-wolpike]

I hope so. sync() was called and filesystem was unmounted. Without truncate() call --- filesystem is clean.

[Chris Johns]

Have a look for 'rtems_disk_fd_sync' in cpukit/libblock/include/rtems/blkdev.h. The block device cache is a complex and defers writes. The sync will flush data to the cache and then the block device cache needs to be flushed to push the data to disk.

[snob-wolpike]

We are aware about it. This code is used:

fd = open(DEVNAME, O_RDWR);
rc = rtems_disk_fd_sync(fd);
close(fd);

[Sebastian Huber]

This is a known bug in our FAT implementation (not the only one). I think we have a duplicate ticket for this.

[snob-wolpike]

Actually both this bug and #2755 can be reproduced using standard "fsrdwr" from RTEMS testsuite. We initially started with it and then simplified to minimal test-cases after sudden Windows comply about "unclean filesystem".

We are able to reproduce both bugs under "native hardware" (QoriQ) and QEMU i386.

[Sebastian Huber]

I think this is a duplicate of #1251. If you want to get this bug fixed, then you probably have to do this job.

[snob-wolpike]

Ok. Just don't close it as "WONTFIX", please.