implement FAT table write/read and setting the volume dirty status

[Murmele]

The dirty flag will be set when opening the volume to indicate that the FAT table might be out of date. In case of an unexpected close without unmount in the next mount it is visible that the FAT table is outdated and can be reread by the operating system (https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system). Without this, the file must always closed before removing the sd card because otherwise the FAT table is outdated and so the files are not visible when mounting the sd card on a computer. For embedded systems it is quite likely that unexpect end can happen and always closing the file after a single write operation is a performance issue. For readonly this dirty flag is not required and therefore it will not set and reset when opening/closing a volume. This is same as the linux kernel is doing.

https://unix.stackexchange.com/questions/230181/why-does-linux-mark-fat-as-dirty-simply-due-to-mounting-it Linux

kernel is doing it during mount, so there is no need to ckeck it every time during a new write

[thejpster]

It appears the tests are failing - possible because the API changed?

[Murmele]

It appears the tests are failing - possible because the API changed?

I will have a look into it next days

[thejpster]

So we already have functions for updating the FAT: FatVolume::update_fat. Could we just create some new ClusterId variants which represent clean/dirty volumes and use the update_fat function to write them to ClusterIdx 1?

[Murmele]

So we already have functions for updating the FAT: FatVolume::update_fat. Could we just create some new ClusterId variants which represent clean/dirty volumes and use the update_fat function to write them to ClusterIdx 1?

My idea was now with this flag, after a restart of my device I check this flag and if dirty I wanna update somehow the dir entries (I think this is currently my problem I have, if I don't update the dirEntry (maybe the size property?) it will not shown in the file explorer correctly). I have to check if I can get there somehow (Maybe iterating through the complete FAT and setting the new file size?).

Sorry right now I am not that deep into the topic to understand your idea. I will think about and doing some research.

But reparing the FAT could be done in another MR

In my case the sd card never leaves the device but at the end over usb storage access shall be established, so I can easily update the FAT at that point

[Murmele]

I fixed the tests

[thejpster]

So we already have functions for updating the FAT: FatVolume::update_fat. Could we just create some new ClusterId variants which represent clean/dirty volumes and use the update_fat function to write them to ClusterIdx 1?

So I like the read-only and read-write changes. If they were isolated I'd happily merge them.

But to return to my earlier comment and perhaps clarify - I don't think we need a whole new module for writing a couple of FAT entries to indicate dirty/clean, when we already have functions which write FAT entries for the purposes of tracking cluster allocations for files. Either all the FAT writing code needs to go in to the new module, or the clean/dirty bits need to be set with the existing function.

[Murmele]

So we already have functions for updating the FAT: FatVolume::update_fat. Could we just create some new ClusterId variants which represent clean/dirty volumes and use the update_fat function to write them to ClusterIdx 1?

So I like the read-only and read-write changes. If they were isolated I'd happily merge them.

But to return to my earlier comment and perhaps clarify - I don't think we need a whole new module for writing a couple of FAT entries to indicate dirty/clean, when we already have functions which write FAT entries for the purposes of tracking cluster allocations for files. Either all the FAT writing code needs to go in to the new module, or the clean/dirty bits need to be set with the existing function.

I will have a look into it. Thanks!