[BUG] FF_Close() does not update xModifiedTime with current system time when file is modified (ffconfigTIME_SUPPORT=1)

[35001215]

Target

• TI MCU platform (e.g., AM64x/AM243x series)
• ffconfigTIME_SUPPORT = 1
• FF_GetSystemTime() implemented and verified to return correct system time

Summary

When appending or modifying a file, FF_Close() does not update xOriginalEntry.xModifiedTime (or xDirEntry.xModifiedTime) with the current system time, even though ffconfigTIME_SUPPORT = 1 and
FF_GetSystemTime() is correctly implemented.

As a result, the FAT directory entry's “last modified timestamp” does not change on file close unless the modified time was manually updated earlier in the write path.

This behavior seems unintended, because FF_PutEntry() simply writes the existing xModifiedTime value into the directory entry without refreshing it.

Reproduction steps

1. Open a file in append or write mode:

   FF_FILE *fp = ff_fopen("/file.txt", "a");
   

Proposed Fix

The root cause is that neither FF_Close() nor FF_PutEntry() updates xOriginalEntry.xModifiedTime (or pxDirEntry->xModifiedTime) to the current system time before storing the directory entry.

To ensure correct FAT "last modified timestamp" behavior, the modified time must be refreshed immediately before the directory entry is written back.

[htibosch]

The FreeRTOS+FAT library is being used for a long time now. We could change FF_Close() and add a call to FF_SetFileTime(), But some users might complain that calling FF_Close() has become slower than it used to be.

We didn't update the timestamps automatically in order to save time. Also, in some cases you want to set the time stamp "manually", for instance when FTP creates a file.

So let add a new config parameters and change FF_Close() a bit.

Before closing the file, test for write access:

if( ( pxFile->ucMode & ( FF_MODE_WRITE | FF_MODE_APPEND | FF_MODE_CREATE ) ) != 0 )
{
    FF_SystemTime_t xTime;
    FF_GetSystemTime( &xTime );
    FF_Error_t FF_SetFileTime( pxFile, &xTime, ETimeMod )
}

It would be good if the timestamp is only written in case it has changed.
Let's give it some thoughts.

[35001215]

@htibosch
Thank you for your comment.
Now, I got your situation.
However, I wonder whether I should use FF_GetSystemTime() or FF_SetFileTime(), and where its location should be. I'd like to ask you that point.

Using FF_GetSystemTime() instead of FF_SetFileTime()

My thought: FF_Close() already calls FF_GetEntry() and FF_PutEntry() when updating the file size. Using FF_SetFileTime() would cause these operations to execute twice, resulting in redundant disk I/O.

Proposed implementation: Insert FF_GetSystemTime() directly between the existing FF_GetEntry() and FF_PutEntry() calls:

• No additional FF_GetEntry() call (already fetched)
• No additional FF_PutEntry() call (single write)
• No additional FF_FlushCache() call
• Minimal performance impact

Placement: Only when file size changes

The timestamp update should be placed inside the condition that checks for file size changes:

if( ( pxFile->ulFileSize != xOriginalEntry.ulFileSize ) || ( pxFile->ulFileSize == 0UL ) )

This ensures the modified timestamp is updated only when actual file content changes, which aligns with standard filesystem behavior and avoids unnecessary updates.

Implementation location

After xOriginalEntry.ulFileSize = pxFile->ulFileSize; and before FF_PutEntry().

This approach reuses the existing directory entry fetch/write cycle, keeping FF_Close() efficient while correctly updating timestamps when files are modified.

Is my understanding correct?