Strange file system problem on Boron 2G/3G

Hello community!

I have a problem with file system on Boron3G OS 6.1. If I repeat this procedure:
(create a file, write to it, sync, close, delete it) two times all consecutive tries result in error (nothing written, write returns -1). Deleting file doesn`t help. Only after power cycle it is possible to write to file again. Below is the code to reproduce it. Any thoughts what could be the case?

#include "Particle.h"

SYSTEM_MODE(MANUAL);
SYSTEM_THREAD(ENABLED);
SerialLogHandler logHandler(LOG_LEVEL_INFO);

void setup()
{
  Serial.begin(115200);
  Serial.printf("\nStarted FILE_TEST");
}

#include <fcntl.h>
#include <sys/stat.h>
#include <dirent.h>
char *fileName = "file.txt";
int ret = 0;
unsigned char ch;
int size = 50000;

void loop()
{
  if (Serial.available())
  {
    ch = Serial.read();
    if (ch == 'u')
    {
      ret = unlink(fileName);
      Serial.printf("\nunlink = %d", ret);
    }
    else if (ch == 'f')
    {
      int f = open(fileName, O_RDWR | O_CREAT);
      Serial.printf("\nopen = %d", f);
      char *buf = (char *)malloc(size);
      for (int i = 0; i < size; i++)
        buf[i] = 0;
      int offset = write(f, buf, size);
      Serial.printf("\nwritten=%d", offset);
      ret = fsync(f);
      Serial.printf("\nfsync=%d ", ret);
      ret = close(f);
      Serial.printf("\nclose=%d ", ret);
    }
    else if (ch == 'd')
    {
      DIR *pDir = opendir("/");
      struct dirent *entry;
      while (entry = readdir(pDir))
      {
        Serial.print("\n");
        if (entry->d_type == DT_DIR)
          Serial.printf("[D] %-20s", entry->d_name);
        else if (entry->d_type == DT_REG)
        {
          struct stat st;
          stat(entry->d_name, &st);
          Serial.printf("[F] %-20s %10d", entry->d_name, st.st_size);
        }
      }
      closedir(pDir);
    }
  }
}

What version of Device OS are you using? There was a bug in removing a file fixed in 5.9.0.

I am using the latest, 6.1.

It looks like you're leaking buf. You allocate it with malloc but I don't see a free.

Since there's only 80K of heap space on the Boron, it will fail the second time. I'm surprised it didn't cause an SOS hard fault because buf will be null. I'd also add an error check after allocation.

2 Likes

Oh... Thanks brother!