Release/v0.6.0

[thejpster]

Changed

• Writing to a file no longer flushes file metadata to the Directory Entry. Instead closing a file now flushes file metadata to the Directory Entry. Requires mutable access to the Volume (#94).
• Files now have the correct length when modified, not appended (#72).
• Calling SdCard::get_card_type will now perform card initialisation (#87 and #90).
• Removed warning about unused arguments.
• Types are now documented at the top level (#86).
• Renamed Cluster to ClusterId and stopped you adding two together

Added

• New examples, append_file, create_file, delete_file, list_dir, shell
• New test cases tests/directories.rs, tests/read_file.rs

Removed

• Breaking Change: Controller alias for VolumeManager removed.
• Breaking Change: VolumeManager::open_dir_entry removed, as it was unsafe to the user to randomly pick a starting cluster.
• Old examples create_test, test_mount, write_test, delete_test

[Murmele]

• Writing to a file no longer flushes file metadata to the Directory Entry. Instead closing a file now flushes file metadata to the Directory Entry.

But this means I have always to close the file. Currently I store a RawFile object (as filehandler) and execute only the write. In this case the file gets created but stays always empty (Currently I don't close the file for testing, but in real scenario this can also happen, so the data is lost?)

Usecase:

• Open File and keep open
• Write data to file (multiple times)
• Device goes off without close -> Data lost?

The problem is when I have to close it, the RawFile "handler" is invalid in my understanding. Is that correct?

Reason why I don't like to close:

• RawFile handler gets invalid
• Slower than just writing

[thejpster]

If closing/re-opening is a performance bottleneck, you could propose a PR containing a flush API, which just looks at the dirty flag and if required, writes to disk and then clears it.

[Murmele]

I thought about the same. I will have a look into it tomorrow and will create a pullrequest. Thanks for the project!

[Murmele]

@thejpster

• Does it make sense to write on the first write also the DirEntry and then again at the end? I tested this. After the first write writing the information once has the effect that when opening the file on the computer, only the part of the first write is visible, but not the rest.

Since DOS 7.1 the two most-significant bits of this cluster entry may hold two optional bitflags representing the current volume status on FAT16 and FAT32, but not on FAT12 volumes. These bitflags are not supported by all operating systems, but operating systems supporting this feature would set these bits on shutdown and clear the most significant bit on startup: If bit 15 (on FAT16) or bit 27 (on FAT32)[41] is not set when mounting the volume, the volume was not properly unmounted before shutdown or ejection and thus is in an unknown and possibly "dirty" state.[27] On FAT32 volumes, the FS Information Sector may hold outdated data and thus should not be used. The operating system would then typically run SCANDISK or CHKDSK on the next startup[nb 9][41] (but not on insertion of removable media) to ensure and possibly reestablish the volume's integrity. Source: https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system

Could this help? So the computer gets the indication that the filesystem was not properly closed and it should rescan?

[thejpster]

There is always a trade off between performance and reliability with FAT.

I like the idea of being able to mark disks as dirty if they have open writable files, and non-dirty when the last writable file has been closed. I just wouldn't want to see read-only access (99% of my use case) mark the FS as dirty.

[Murmele]

There is always a trade off between performance and reliability with FAT.

I like the idea of being able to mark disks as dirty if they have open writable files, and non-dirty when the last writable file has been closed. I just wouldn't want to see read-only access (99% of my use case) mark the FS as dirty.

Haha then we have opposite usecases 😄 i have most of the time writing. Neverthless, I will check this flag out. I don't think during read the dirty flag will be set