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

Activity

1. 35001215

   added

   bugSomething isn't workingSomething isn't working

   on Feb 5, 2026
2. htibosch commented on Feb 20, 2026

   

   htibosch

   on Feb 20, 2026

   Contributor

   More actions

   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.
3. 35001215 commented on Feb 24, 2026

   

   35001215

   on Feb 24, 2026

   Author

   More actions

   @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?
4. Old-Ding commented on Jul 4, 2026

   

   Old-Ding

   on Jul 4, 2026

   More actions

   I opened PR #86 following the config-gated approach discussed here: ffconfigUPDATE_FILE_MODIFIED_TIME_ON_CLOSE defaults to 0, and when enabled the timestamp update reuses the existing FF_Close() directory-entry write for files that were actually modified.