MS-DOS File System questions - partitions, mounting, files

[Robert S. Grimes]

Hi Chris,

First, I should offer to save you some time by noting I've figured this 
all out.  For completeness, I've answered some of your questions below, 
in the hope of illuminating my confusion.  I'm not sure if what I've 
encountered can be used by others, but just in case, here goes.


Chris Johns wrote:
>
>>     // According to Chris' Wiki entry on MSDOS, I need to do this, but
>>     it fails with a "Not supported"
>>     // error.  Questions:
>>     //
>>     //   1. I'm not sure what to do with the mtEntry parameter - is it
>>     used for other functions?
>>     //   2. I'm not sure about "/mnt/dirone". As I said above, there is
>>     a directory on my SD card
>>     //      called dirone, but I'm not sure that I'm doing things
>>     correctly.  I guess my real question
>>     //      is: How do I mount the SD card such that its entire contents
>>     are available to my app?
>>     rtems_filesystem_mount_table_entry_t* mtEntry;
>>     if (mount(&mtEntry, &msdos_ops, RTEMS_FILESYSTEM_READ_WRITE,
>>     "/dev/sdcarda1", "/mnt/dirone") < 0) {
>>       printf("mount: mount failed: %s\n", strerror (errno));
>>     }
>>     
>
> I think this call fails because you have already mounted the SD card under
> /mnt and this call attempts to mount it again on an MSDOS file system and I
> think mounting is not supported on the MSDOS file system. This is the source
> of the not supported error.
>
> You only need to mount the file system once so you either mount with the
> fsmount command or the mount command and not both. There is no correct or
> better solution here so you can decide which one best suites your needs.
>   
Yes, of course, you are correct.  I got a bit confused here, and for a 
while, I thought I was dealing with a "read-only" file system.  So I 
convinced myself that I had to use the mount() call as illustrated in 
your Wiki page, and mistakenly guessed that fsmount() and mount() were 
different, and both necessary.  Later, of course, I could no longer 
confuse myself, especially when looking at the fsmount() call again, 
and  noting it was mounting in read/write mode.  It is good to know, 
however, that the two (fsmount() and mount()) are relatively equivalent, 
as that means two "experts" are not at odds!

>   
>>     // Interestingly, this works just fine, even with the previous mount...
>>     int readme = open("/mnt/README.TXT", O_RDONLY);
>>     char linebuf[32];
>>     linebuf[0] = '*';
>>     linebuf[1] = 0;
>>     rv = read(readme, linebuf, 27);
>>     if (rv > 0) {
>>       linebuf[rv] = 0;
>>       printf("Readme contains: [%s]\n", linebuf);
>>     } else {
>>       printf("Failed to read file - return code: %d\n", rv);
>>     }
>>     close(readme);
>>     
>
> This shows the SD card is mounted. Great.
>   
Yes, and this worked rather early on - however, my confusion prevented 
me from believing in my successes!

>   
>>     // This doesn't work fully, though the mkdir sometimes works enough
>>     that Windows will see
>>     // the new directory; when it does, it is sometimes okay, sometimes
>>     corrupted.  Questions:
>>     //   1. Is this the correct way to do it?
>>     //   2. Is the mount() failure the cause of this one?
>>     
>
> The "sometimes works" could be important. More on this in a moment.
>
> The partition needs to be mounted read/write. If mounted read only then these
> actions fail. The fsmount table will hold the options used.
>   
Yes, this is an important point.  As it was, I was using the read/write 
option.

> The "sometimes works" could point to the application halting before the cache
> has written all the data to disk. The cache has a hold time where buffers wait
> a configurable period of time before being written to disk. This improves
> performance with the MSDOS file system. It may how-ever not sit well with
> specific applications therefore the 'sync' call is provided. The standard call
>   only covers the open files and not the RTEMS specific cache. The cache also
> needs to be flushed. You can find an example of how do this in the shell in
> the blksync command. The file is cpukit/libmisc/shell/main_blksync.c. The
> device is the device you mounted, ie /dev/sdcarda.
>
> The rule is simple. If your applications needs the data to be on disk then
> sync the file system buffers (sync) and sync the block device cache before it
> terminates.
>
> If you have not waited until the data has been written the disk could be
> corrupted and needs to be fixed or reformatted.
>   
This is indeed what was causing the "sometimes works" problems - again, 
only my confusion can explain why I didn't think of it sooner.  At some 
point, though, some clarity made it through the fog, and a call to 
unmount() before the end of my test code, and sure enough, that fixed 
that problem.  That said, the extra information (i.e. blksync) is of 
great importance to me, and I'm glad you mentioned it here - I had not 
heard of it nor run across it to this point.  Thanks!!!

Take care,
-Bob