LittleFS problem with file time

Libraries
1

The date of the file created is aways 2000-01-01
I set the callback end return a valid date, but the file date don’t change.

2

I’m not quite understanding that. Can you show the exact platformio.ini and code that you’re using a test here?

It might also be that it’s just not implemented.

3

CONFIGURATION: Redirecting...
PLATFORM: Espressif 8266 (2.6.3) > NodeMCU 1.0 (ESP-12E Module)
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES:

  • framework-arduinoespressif8266 3.20704.0 (2.7.4)
  • tool-esptool 1.413.0 (4.13)
  • tool-esptoolpy 1.30000.201119 (3.0.0)
  • tool-mklittlefs 1.203.210203 (2.3)
  • tool-mkspiffs 1.200.0 (2.0)
  • toolchain-xtensa 2.40802.190218 (4.8.2)
4

time_t setFileTime(){
setLocalTime();
char buf[25];
sprintf(buf,"%04d-%02d-%02dT%02d:%02d:%02d",year(),month(),day(),hour(),minute(),second());
Serial.println(buf); // the date is correct here and this message is show each time I save a file…

return local;

}

void initLittleFS() {
LittleFS.begin();
LittleFS.setTimeCallback(setFileTime);
}

5

Where does this variable come from? This doesn’t seem like the complete code.

6

This is the code to start LittleFS. The variable local contains the current date time set by Ntp. The type of the variable is time_t as requested by the callback function.

this is the code to create a file:

File dataFile;
LittleFS.remove(“Test.txt”); // to be shure to create a new file. normally not needed.
dataFile = LittleFS.open(“Test.txt”,“w”);
dataFile.println(“123456”);
dataFile.close();

7

…Well it’s still not the complete code, so I can’t reproduce / compile it.

When I use the example sketch Arduino/LittleFS_Timestamp.ino at master · esp8266/Arduino · GitHub fro

but change the line for configTime to

  /* instead of harcoded offsets, use timezone string per https://github.com/esp8266/Arduino/blob/master/cores/esp8266/TZ.h  */
  configTime(/*3600 * timezone, daysavetime * 3600*/ TZ_Europe_Berlin , "time.nist.gov", "0.pool.ntp.org", "1.pool.ntp.org");

(and I adapt STASSID and STAPSK), it works nicely.

Connecting to <wifi name>
.......WiFi connected
IP address:
192.168.1.XXX
Contacting Time Server

Now is : 2021-02-27 00:42:34

Formatting LittleFS filesystem
Mount LittleFS
Listing directory: /
Deleting file: /hello.txt
Delete failed
Writing file: /hello.txt
File written
Appending to file: /hello.txt
Message appended
Listing directory: /
  FILE: hello.txt  SIZE: 13    CREATION: 2021-02-27 00:42:34
  LAST WRITE: 2021-02-27 00:42:36
The timestamp should be valid above
Now unmount and remount and perform the same operation.
Timestamp should be valid, data should be good.
Now mount it
Reading file: /hello.txt
Read from file: Hello World!
Listing directory: /
  FILE: hello.txt  SIZE: 13    CREATION: 2021-02-27 00:42:34
  LAST WRITE: 2021-02-27 00:42:36

Time is correct at the time of writing and the LittleFS timestamps are shown correctly, too. No LittleFS.setTimeCallback() needed, it seems to use the current system time, that is synchronized via NTP in that example.

8

Finally I solved the problem: It take a long time (in my case 27 seconds) to received the good date and time !

This is my code:
Serial.println(“WiFi connected”);
Serial.println("IP address: “);
Serial.println(WiFi.localIP());
Serial.println(“Contacting Time Server”);
configTime(0,0,“pool.ntp.org”);
setenv(“TZ”,“CET-1CEST,M3.5.0,M10.5.0/3”,0);
delay(3000);
int n=0;
while(time(nullptr)<=100000){
n++;
time_t tnow = time(nullptr);
Serial.print(n);
Serial.print(” “);
Serial.println(String(ctime(&tnow)));
delay(1000);
}
time_t tnow = time(nullptr);
Serial.print(n);
Serial.print(” ");
Serial.println(String(ctime(&tnow)));

and the the result:

Contacting Time Server
1 Thu Jan 1 00:00:03 1970
2 Thu Jan 1 00:00:04 1970
3 Thu Jan 1 00:00:05 1970
…
…
25 Thu Jan 1 00:00:27 1970
26 Thu Jan 1 00:00:28 1970
27 Thu Jan 1 00:00:29 1970
28 Sat Feb 27 19:59:30 2021

If i try to create or modify a file directly after configTime, the date and time are not set and LittleFS use an incorrect date and time.

The function configTime is probably asynchrone…