#2757 assigned defect

truncate() is broken for FAT

Reported by: snob-wolpike Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: fs/fat Version: 4.11
Severity: normal Keywords:
Cc: Blocked By:


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));
    for(int i = 0; i < 256 * 1024; i += 1)
        fprintf(f, "Test message buffer bum %i\n", i);
    if(truncate(TEST_FILENAME, 0) != 0)
        printk("truncate() failed: %i %s\n", errno, strerror(errno));

Both 4.11 and 4.12 affected

Change History (12)

comment:1 Changed on Jul 12, 2016 at 11:19:53 AM by snob-wolpike

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

comment:2 Changed on Jul 12, 2016 at 12:00:43 PM by Chris Johns

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

comment:3 Changed on Jul 12, 2016 at 12:02:17 PM by snob-wolpike

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

comment:4 Changed on Jul 12, 2016 at 12:15:42 PM by 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.

comment:5 Changed on Jul 12, 2016 at 12:24:19 PM by snob-wolpike

We are aware about it. This code is used:

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

comment:6 Changed on Jul 12, 2016 at 12:30:42 PM by Sebastian Huber

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

comment:7 Changed on Jul 12, 2016 at 12:44:39 PM by 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.

comment:8 Changed on Jul 12, 2016 at 12:48:58 PM by 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.

comment:9 Changed on Jul 12, 2016 at 12:51:35 PM by snob-wolpike

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

comment:10 Changed on Jan 26, 2017 at 7:16:00 AM by Sebastian Huber


comment:11 Changed on Feb 15, 2017 at 1:44:44 PM by Sebastian Huber

Milestone: 4.11.2Indefinite
Owner: set to Needs Funding
Status: newassigned

comment:12 Changed on Oct 10, 2017 at 6:50:58 AM by Sebastian Huber

Component: fsfs/fat
Note: See TracTickets for help on using tickets.