On Thu, Jul 30, 2009 at 10:53 AM, James Walmsleyjames@worm.me.uk wrote:
Actually thats just being developed into FullFAT already in preparation for the 1.0.0 release. I believe I already mentioned it, but here's a link the the linux kernel mailing list that explains how the patch works and why its legally valid.
http://lkml.org/lkml/2009/6/26/314 -- A legal discussion about the patch. http://lkml.org/lkml/2009/6/26/313 -- Technical details of what the patch does.
FAT stores a checksum in LFNs of the shortname, this can be used to verify the integrity of LFN entries in a directory. Of course using the linux patch, the short name can be used for other puposes. However its not really journaling because you still have to scan all the directories. This takes a long time.
Right. The set of patches I am thinking of is actually older than Tridge's recent patent avoidance work. But I think the concept was the same. If there is a performance hit then it would not worth it.
Sarocet also makes a good point about the problem with a ReactOS journaling file. The journal should store some kind of hash or checksum value of the state of the FAT table (which is probably too big). Or atleast the directories affected by the journal changes. If this hash differs before journal transactions are committed to the FS then the journal should clear that transaction and not commit it.
Really journaling should only be enabled for a ReactOS system partition, using journaling on removable media wouldn't bring any great benefit, because of the effect that Sarocet described.
Still I think the journaling is something we won't add until the driver is working and stable.
I agree. It would be nice to have but that is way down the road but for now, it would just be nice to have a bullet proof fat32 implementation although I suspect a lot of our problems are deeper than the driver itself. If I recall there has been quite a bit of work in the past to get our vfat driver to function on Windows.
Thanks