FAT32 with LFN support weirdness
Posted: Mon Mar 23, 2015 8:45 am
I'm having some problems with an auto-ftp transfer program being able to delete files off of my SDHC card after it has downloaded them, but only if the number of files in the folder is large.
I was wondering if there was a problem related to the maximum number of files allowed in a FAT32 folder, so I performed a test. According to the spec for FAT32, there are up to 65534 files that can be stored in a folder (65536 directory entries minus 1 for '.' and one for '..'). However, if using long filenames, there are multiple directory entries used per filename (from 1 to 13). One entry is used for the 8.3 filename, and additional entries are used for the long filename (1 entry for every 13 characters). So, a filename with 67 characters would use up (1 + 67/13) entries, which is ~6.15. It therefore needs 7 entries per filename. Now taking 65534 / 7 gives 9362 files allowed in a folder.
Given all of that, I performed the following test:
1) I created 9,362 files with a filename length of 67 characters.
2) Using Windows, I copied all of these files to a subfolder on my SDHC card, which was inserted into a PC Card slot.
3) I tried to copy one additional file to the folder, and got an error in a dialog box because the limit had been reached. Woo Hoo, it did what I expected!
4) I then deleted five files from the folder to be able to create some files in my Netburner system.
5) I then inserted the SD card into my Nano-based equipment, which periodically writes files to the SD card with filename length of 67.
6) I watched my MTTY debug output and waited, expecting a file open to fail when I tried to open file number 9363.
7) The system just kept on writing files just fine. I stopped after 12 new files were written.
8) I took the card and put it back into my Windows computer, and the file directory showed all of the files.
9) I was able to COPY MORE files into the folder without getting any dialog box error!
10) I finally tried doing a right-click and Properties on the folder, expecting to see the number of files in the folder. I just got the busy cursor, and nothing ever happened. I had to stop and restart Windows Explorer, so something was obviously wrong on the card.
So the questions I have are:
1) Is there a problem with the EFFS code that does not properly determine if the directory entries are full? I'm doing an error check on file opens, and got no error.
2) Why does the folder still look normal, e.g. all filenames are properly displayed?
With respect to the file deletion problem, I think this might be unrelated because the number of files in the folder was below 2,000. Is there a problem with the FTP file delete (maybe a socket issue)? When this failure occurred, I was no longer able to access my file system via FTP, like something was hung up.
This failure only occurred when trying to auto-download a large number of files in a single FTP session, which would occur if I stopped the file transfer program for a long period of time while the Netburner was storing files, and then started it up. It would get the file list OK, and would successfully transfer a bunch of files, deleting each one from the SD card after transfer was complete, but it would eventually report that the file or folder did not exist (even though it got it from the file list). Once it started doing this, I could no longer access my file system at all, even when trying to open the FTP site in Windows Explorer (no response).
If anyone has any insight into either of these issues, I'd appreciate your input.
I was wondering if there was a problem related to the maximum number of files allowed in a FAT32 folder, so I performed a test. According to the spec for FAT32, there are up to 65534 files that can be stored in a folder (65536 directory entries minus 1 for '.' and one for '..'). However, if using long filenames, there are multiple directory entries used per filename (from 1 to 13). One entry is used for the 8.3 filename, and additional entries are used for the long filename (1 entry for every 13 characters). So, a filename with 67 characters would use up (1 + 67/13) entries, which is ~6.15. It therefore needs 7 entries per filename. Now taking 65534 / 7 gives 9362 files allowed in a folder.
Given all of that, I performed the following test:
1) I created 9,362 files with a filename length of 67 characters.
2) Using Windows, I copied all of these files to a subfolder on my SDHC card, which was inserted into a PC Card slot.
3) I tried to copy one additional file to the folder, and got an error in a dialog box because the limit had been reached. Woo Hoo, it did what I expected!
4) I then deleted five files from the folder to be able to create some files in my Netburner system.
5) I then inserted the SD card into my Nano-based equipment, which periodically writes files to the SD card with filename length of 67.
6) I watched my MTTY debug output and waited, expecting a file open to fail when I tried to open file number 9363.
7) The system just kept on writing files just fine. I stopped after 12 new files were written.
8) I took the card and put it back into my Windows computer, and the file directory showed all of the files.
9) I was able to COPY MORE files into the folder without getting any dialog box error!
10) I finally tried doing a right-click and Properties on the folder, expecting to see the number of files in the folder. I just got the busy cursor, and nothing ever happened. I had to stop and restart Windows Explorer, so something was obviously wrong on the card.
So the questions I have are:
1) Is there a problem with the EFFS code that does not properly determine if the directory entries are full? I'm doing an error check on file opens, and got no error.
2) Why does the folder still look normal, e.g. all filenames are properly displayed?
With respect to the file deletion problem, I think this might be unrelated because the number of files in the folder was below 2,000. Is there a problem with the FTP file delete (maybe a socket issue)? When this failure occurred, I was no longer able to access my file system via FTP, like something was hung up.
This failure only occurred when trying to auto-download a large number of files in a single FTP session, which would occur if I stopped the file transfer program for a long period of time while the Netburner was storing files, and then started it up. It would get the file list OK, and would successfully transfer a bunch of files, deleting each one from the SD card after transfer was complete, but it would eventually report that the file or folder did not exist (even though it got it from the file list). Once it started doing this, I could no longer access my file system at all, even when trying to open the FTP site in Windows Explorer (no response).
If anyone has any insight into either of these issues, I'd appreciate your input.