Restatement of the problem:
===================
Files on some types of filesystems, such as Apple’s HFS+, and I think zfs, have both a data fork and a resource fork. Conventionally, we check for data corruption (such as a flipped bit) by comparing the md5sum or sha1 checksum of a possibly corrupted file with an uncorrupted file. If the checksums are identical, we are happy. However, you can change the information in the resource fork, and you can corrupt it, but this doesn’t change the checksum of the data fork, but can (as I found out the hard way) nevertheless corrupt the file.
Summary of on-topic replies:
===================
A few respondents confirmed that this is indeed potentially problematic. As far as I have understood, no one suggested how this could be detected automatically. One person suggested deleting the potentially corrupted resource forks with xattr -d if a problem copying the file arises. (I had not thought of this before I deleted my corrupted files, so I haven’t had a chance to test it, but this sounds very promising.)
Conclusion:
=======
I’m still not clear on whether a zsf or btrfs self-healing RAID will detect and correct corruption in resource forks, or if storing data on these kinds of file systems simply eliminates the problem (and the horror of resource forks and extended attributes).
Acknowledgement:
============
Thanks to all those who replied both off and on-line.
All the best,
Bill
William G. Scott
Director, Program in Biochemistry and Molecular Biology
Professor, Department of Chemistry and Biochemistry
and The Center for the Molecular Biology of RNA
University of California at Santa Cruz
Santa Cruz, California 95064
USA
|