MFS provides an ioctl function for getting the long filename of a file. There are several problems:
1. The documentation (MQXMFSUG 2.6 section 3.8.1.24) describes IO_IOCTL_GET_LFN and says "The third parameter is the char_ptr to the path name of the of file which we want
the long filename of". This is not true. The third parameter is not a pointer to char, it is a pointer to a struct of type MFS_GET_LFN_STRUCT. The function prototype and example code are correct, but the text description is wrong.
2. MFS_GET_LFN_STRUCT, which you provide to ioctl(IO_IOCTL_GET_LFN) has three fields:
typedef struct mfs_get_lfn_struct {
char_ptr PATHNAME;
char_ptr LONG_FILENAME;
MFS_SEARCH_DATA_PTR SEARCH_DATA_PTR;
} MFS_GET_LFN_STRUCT, _PTR_ MFS_GET_LFN_STRUCT_PTR;
The intended operation appears to be that you fill in PATHNAME with the short path name, call ioctl(IO_IOCTL_GET_LFN) and it fills in LONG_FILENAME. The third field, SEARCH_DATA_PTR, is unused.
The problem comes when you call ioctl(IO_IOCTL_GET_LFN) and pass it an MFS_GET_LFN_STRUCT that has been created for you by calling ioctl(IO_IOCTL_FIND_NEXT_FILE). This is a fairly obvious workflow and is used for example in _io_mfs_dir_read(). The problem is twofold:
- ioctl(IO_IOCTL_FIND_NEXT_FILE) fills in the PATHNAME field not with the path but with just the filename. The path is omitted.
- ioctl(IO_IOCTL_GET_LFN) does a brain-dead search for the short filename starting at the root of the filesystem. Since short filenames are not unique across the whole filesystem (only in a given directory) it may or may not find the right file. What you get back may be the long name for the file you wanted, or for a completely different file in a different directory that happens to have the same short name.
You can easily see this issue, for example on a K60 tower using the shell "dir" command in the stock example application. Create files on an SD card with the following directory structure using a PC, put the card in the tower, then use the shell dir command. Look carefully at the long filename for the file in the subdirectory; it's wrong.
This is not the fault of the Shell_dir() command. It is caused by the underlying _io_mfs_dir_read() as described above.
