3

Is it possible to retrieve the checksums/hashes that ReFS creates for integrity streams? I found this document which describes a new API control code: FSCTL_GET_INTEGRITY_INFORMATION, but it seems to only get some details about the integrity stream like checksum type and chunk size, not the checksums themselves.

I'm interested in this information because I'm writing a program that needs to identify file change more robustly than just file-name and time-stamp, and I'd hate to re-do all the checksumming that the filesystem is already doing, especially since I'm working with terabytes of data.

  • In a document here: http://www.microsoft.com/en-us/download/details.aspx?id=29043 "ReFS supports two types of data streams, conventional streams and integrity streams. Conventional streams: Streams that do not provide any integrity protection. From a functional perspective, conventional streams behave identically to NTFS streams."... Do you think you'd be able to access the integrity stream checksum (CRC64) data via a different data stream call? – mttjohnson Apr 23 '13 at 17:35
  • ReFS has dropped support for alternate data streams. Nevertheless, I used this utility http://www.nirsoft.net/utils/alternate_data_streams.html to look for ADSes on my my ReFS volume, but came up empty-handed. I don't know how the checksum data is stored, but it would be silly for Microsoft to remove ADSes just to reimplement them with their only new purpose being to store a separate data stream for integrity stream checksums. Storing the data with the rest of the filesystem metadata also seems silly though, so I'm really not sure. – Hanyou Hottie Apr 27 '13 at 06:25

1 Answers1

1

I think you are not supposed to access the checksums directly. There is one CRC64 checksum per 64 KB cluster in a file (you might get tons of them for large files). They are stored in a "private" way for the filesystem without an API access to it that i know. From what i know of the binary format in 2012R2, there is no ADS to access the checksums, you have to dig in the partition.

As for the initial concern, you may be interested in FILE_ATTRIBUTE_NO_SCRUB_DATA. Its purpose is "This attribute is useful for those applications that maintain their own integrity information, when the application developer wants tighter control over when and how those files are scrubbed.". That is close to what you want.

Best regards.

REFS
  • 36
  • 2