rename() fails and file size 0.

[ndjur]

Hi.
I have a problem renaming a file in littleFS.

Here is the simple code:

    sprintf (newName, "/%s/%sA_%04d.%s", logFileNamePrefix, logFileNameArchive, archiveNum, logFileNameExt);
    printf ("This fails: New file name is %s. File name size is %d\n", newName, strlen(newName));
    sprintf (newName, "/%s/%sB.%s", logFileNamePrefix, logFileNameArchive, logFileNameExt);
    printf ("New file name is %s. File name size is %d\n", newName, strlen(newName));

    if (unlink(newName) == 0) // delete if already exists
      printf ("Deleting file with same dest. name (%s).\n", newName);
    else
     printf("Nothing to delete. Renaming...\n");

    if (rename((const char *)pFileName, (const char *)newName) == 0)
    {
      // do something 

Why is the newName changed twice?

The first time it didn't work. The application would hang inside "rename" and there was no further debug output that should be there. After changing the code to a shorter newName, everything started working again. However, even the first "newName" is shorter than 32 characters, so I'm wondering what has happened and of course, how come that rename() function would completely and silently mess up the application? I also tried to skip calling rename() and in this case the rest of the application was executed correctly.

Output from the listed code:

This fails: New file name is /LOGS/appLogA_0194.txt. File name size is 22
New file name is /LOGS/appLogB.txt. File name size is 17
Deleting file with same dest. name (/LOGS/appLogB.txt).
File /LOGS/appLog.txt renamed to /LOGS/appLogB.txt.

Also, one more question.

Both stat() and fseek(end)/ftell show file size 0 for some small files that were opened in append mode, test appended with occasional flushing, closed, opened again in read mode, their content read and listed and then closed again.
Any ideas why?

Thanks a lot

[ndjur]

I just tried the same application with the same workflow using spifFS. All files that littleFS reports as 0 in size are reported as 1024 bytes in size.
Do you think that this is expected behavior by these two file systems?

[BrianPugh]

The test for rename is here and works fine:

https://github.com/joltwallet/esp_littlefs/blob/master/src/test/test_littlefs.c#L275

Do you have some odd concurrency going on? If your application is hanging inside rename, it's probably attempting to take the already taken mutex.

[ndjur]

Thanks a lot Brian,

Due to the problems with rename(), I switched to spifFS, but as soon as I have time I'll go back to littleFS and try again. At the moment, I'm really not sure how can semaphore be taken and not released by some other file operation and how can rename() be affected by the file name string size (and it looks like it is).
BTW, do you have any insight on the reported file size I mentioned in my earlier post?
Thank you very much.

[BrianPugh]

so I'm not sure if these are issues with my port, or just upstream littlefs. Here are few upstream issues that may be relevant:

lfs_rename sometimes very slow

I'll add more if i find them

[BrianPugh]

so i think i might know what the issue is, it's related to by not-to-spec negative return codes. will update later.

[ndjur]

Thanks a lot Brian.

[BrianPugh]

Alright, so i revamped some of the error handling in #75 ; there were some unforeseen bad interactions between my port and the esp vfs. I wasn't quite following the functions to spec; i now return exactly -1 on errors and set the errno. Please pull the latest changes and see if it resolves your issues.

I imagine in your scenario I was previously returning a negative value (indicating an error), but vfs would somehow interpret it back to a zero. When you get a -1 return value, check the errno for what could have gone wrong.

Once you confirm this fixes your issue, i'll probably cut a new version in the next few days.

[ndjur]

Thank you very much Brian, but due to this problem I decided to switch to SpifFS so at the moment I'm not able to test your change. However, I will gladly find a "blank" ESP32 and run my software with LittleFS enabled instead of SpifFS. I'll certainly let you know how it goes.
Thanks again for your effort.

[BrianPugh]

I just pushed a fix for a broken rename in certain situations when CONFIG_LITTLEFS_SPIFFS_COMPAT is enabled (#77).

If your problem was exactly as described, I don't believe it would have caused your issues, but it could have if your destination was a folder that did not already exist.

[BrianPugh]

I'm going to mark this as resolved for now. If it isn't actually we can always re-open.