MFS on MQX 4.2 problem when multiple files with common name root in same directory

[lfschrickte]

Hi folks,

I'm getting a strange behavior on MFS on MQX 4.2 - which was not occurring on MQX 4.1.

I am writing logs to a log directory (a:/log) on the SD card, sequentially: every time a log file reaches some fixed size a new file is created. Log filenames follow this pattern:  logN.txt

I've noticed however that, after a certain number of logs are created (it looks like the magical number is 127), if I close the file handle and try to open it again I get a "file not found" error. Even the shell "del" command doesn't work with this file (however I can mount the filesystem normally on windows and delete the file).

I've tried to debug the mfs code and it looks like it is failing on LFN calculations on the MFS_scan_dir_chain function (file mfs_dir_chain.c) - it returns file not found error - even the file being in there.

Another clue is that if I delete the previous file (log126.txt, as I can't delete log127.txt) the following returns from a dir command:

Shell default dir command response

.... LOG115.TXT        136 07-27-2015 19:51:40      A LOG115.TXT LOG116.TXT        136 07-27-2015 19:51:42      A LOG116.TXT LOG117.TXT        134 07-27-2015 19:51:42      A LOG117.TXT LOG118.TXT        140 07-27-2015 19:51:42      A LOG118.TXT LOG119.TXT        136 07-27-2015 19:51:42      A LOG119.TXT LOG120.TXT        136 07-27-2015 19:51:44      A LOG120.TXT LOG121.TXT        134 07-27-2015 20:23:18      A LOG121.TXT LOG122.TXT        132 07-27-2015 20:23:22      A LOG122.TXT LOG123.TXT        130 07-27-2015 20:23:28      A LOG123.TXT LOG124.TXT        128 07-27-2015 20:23:38      A LOG124.TXT LOG125.TXT        134 07-27-2015 20:23:52      A LOG125.TXT 14380240.29, 858797106 09-20-2005 06:08:20  HS DA 14380240.29,

There is some garbage at the listing end. I'm not sure that both problems are related, though.

I've tried different SD cards already and also tried to delete all files, however the problem is always there again!

Thanks in advance - any help will be appreciated!

[josephchen]

Hello Luiz,

I have also encountered similar problem in MFS of MQX 4.2. There's a lot changed in MFS from 4.1 to 4.2, and I have discovered a lot bugs in it. It seems this issue usually occurs when the SD card is larger than 1GB. The problem may be solved when you reformat the SD card with larger cluster size. You may set the table in mfs_format.c. However, I think it's better to use MFS of MQX 4.1 for now since there're still potential problem existed in the new version. I have tested to use MQX 4.2 with MFS 4.1, and it works fine.

[lfschrickte]

Thanks Joseph.

It's kind of disappointing to know that! Freescale advertised that it has improved the MFS system and has solved a lot of bugs. I didn't expect it to be that unstable!

I've tried to integrate MFS from MQX 4.1 on my 4.2 compilation without success - it was a couple weeks ago and I don't remember what happened, but as you were successfull doing it I think it is worth a new try!

Thanks again for your reply, I was hopeless about this question already.

Luiz

[josephchen]

TWRK64 MQX 4_2 MFS SD-CARD demo Volume and LFN long file name collision

Here's some discussion about MQX 4.2 MFS including some fixed MFS files. However, I haven't tried it yet. I guess it's still better to wait for the next official release or patch.

[lfschrickte]

Thanks Joseph,

I've moved on in my project limiting the number of logs in the same directory to 100, so I've no time right now to check if I can use MQX 4.1 filesystem - but I'll do in the coming weeks and if I need help I'll let you know!

I think the problem the guys are talking about in this TWRK64 topic is the same as the on I've experienced - I'll let them know of this alternative way to reproduce the issue!

Thank you very much!

Luiz

[josephchen · Accepted solution]

Hello Luiz,

     I have tested those fixed MFS files for MQX 4.2, and it does solve the issue I have encountered.

Joseph

[josephchen]

May you show the error message so I can see if I can help you. Also, please note that when you do file search in MFS from MQX 4.1, there's one more variable in the LFN structure that needs to be set, which is different from MQX 4.2.

[lfschrickte]

Is there anything I can supply to make it easier to test this condition so I may have an answer from freescale?

I'm pretty convinced it may be a serious problem in MFS (not being allowed to write to a file in a directory with more than 127 files).

Thanks

Luiz

[lfschrickte]

It looks like the problem is not related to LFN - I've tried using 8.3 names and the problem persists.

In order to make it easy to replicate the problem I've create a shell command, which can be used in the shell example to create fake files in an empty FAT32 SD card:

Fake file creation command for shell
int32_t cmd_fake_files(int32_t argc, char *argv[]) {    bool print_usage, shorthelp;    int i, n, oper;    MQX_FILE_PTR f;    char filename[32], froot[4];    print_usage = Shell_check_help_request(argc, argv, &shorthelp);    if (!print_usage) {    /* create or delete files? */    if (strcmp(argv[1], "delete") == 0) { oper = 0; }    else if (strcmp(argv[1], "create") == 0) { oper = 1; }    /* number of files to create/delete */    n = strtoul(argv[2], NULL, 10);    for (i=0;i<n;i++) {    /* create random names */    if (!(i % 4)) { strcpy(froot, "ABC"); }    else if (!(i % 3)) { strcpy(froot, "DEF"); }    else if (!(i % 2)) { strcpy(froot, "GHI"); }    else { strcpy(froot, "JKL"); }    /* optional third parameters allow writing in a subdir (which must be created first) */    if (argc > 3) { sprintf(filename, "a:/%s/%s%d.TXT", argv[3], froot, i); }    else { sprintf(filename, "a:/%s%d.TXT", froot, i); }    /* create/delete files */    if (oper) {   f = fopen(filename, "w+");   write(f, filename, strlen(filename));   fclose(f);   } else {    /* delete files */   _io_ioctl(mfs_fd_ptr, IO_IOCTL_DELETE_FILE, (uint32_t *) filename);   }   _time_delay(10);   }   }    return 0; } const SHELL_COMMAND_STRUCT Shell_commands[] = { /*** other commands ommited ***/   { "fakef", cmd_fake_files },   { NULL,  NULL } };

So, in order to reproduce the problem I create a TMP directory, call the command to create 128 pseudorandom name files in this dir and try to read their content (yes, I know the code is ugly - I just didn't want to spend a lot of time in order to prove my point). Here is the sequence:

Sequence of commands to reach the error

shell> mkdir TMP shell> fakef create 128 TMP (create 128 files in the /TMP directory) shell> cd TMP shell> dir .... (121 files omitted here) JKL121.TXT         17 07-28-2015 16:27:06      A JKL121.TXT GHI122.TXT         17 07-28-2015 16:27:06      A GHI122.TXT DEF123.TXT         17 07-28-2015 16:27:06      A DEF123.TXT ABC124.TXT         17 07-28-2015 16:27:06      A ABC124.TXT JKL125.TXT         17 07-28-2015 16:27:06      A JKL125.TXT DEF126.TXT         17 07-28-2015 16:26:14      A DEF126.TXT JKL127.TXT         17 07-28-2015 16:27:06      A JKL127.TXT shell> type JKL125.TXT a:/TMP/JKL125.TXT (file content correctly shown) shell> type DEF126.TXT Error, unable to open file DEF126.TXT. shell> type JKL127.TXT Error, unable to open file JKL127.TXT. shell>

So I can open and see the content of the first 126 files - however from the 127th file on the system fails opening the file! It is useless to delete any of the other files or to restart the system. This example also proves that the filename has no influence over the problem that I can have a maximum of 126 files in the same directory =(

The filesystem works perfectly in a Windows system, however. Any idea of what I'm doing wrong or if the system has a bug?

Any help will be appreciated!

Thanks!