Directory hash as one string

[FatBit]

Dear forum memebers,

what do you think about directory hash as a content (sub)directory tar (or something like this, without real processing) + hash? According to my opinion the advantage is only one string as a change flag. Next processing step can continue with "ordinary" file hash function.

Sincerely yours,

FatBit

[m^2]

Could you say some more? I have no idea what are you talking about.

[FatBit]

I apologise for my poor explanation. E. g. when Linux distributes its files, they are collected and compressed into one file (e. g. .iso) and check hash MD5 value is calculated. And my idea is following: to compute directory check hash value "withouth" collection step. Internally it is probably necessary to make collection step as somethink like tar, but externally I compute "directory hash" for one directory hash string, not many hashes for all files.

Sincerely yours,

FatBit

[Piotr Tarsa]

Probably you can do that using pipes ie something like:
tar -c *.* | md5sum

[FatBit]

Yes, I agree. But I think that it is at least drive space consuming and unnecessary step. It would be better "to integrate" tar -c *.* | md5sum step into file hash tool as a temporary calculation step. Or not to use tar step and during directory tree reading to calculate hash value (not only MD5!) "on the fly".

Sincerely yours,

FatBit

[Piotr Tarsa]

It should not use any temporary space, besides small in-RAM buffer.
cat /dev/urandom | md5sum doesn't consume any disk space either.
The drawback is that above command produces only md5 hash, one would need to write a wrapper that eats data from stdin and outputs that data to multiple hashers, eg md5sum, sha256sum, sha1sum, etc But that should be easy.

[m^2]

I wonder whether there's a filesystem with such capability. Tahoe-LAFS and ZFS both have quite similar features, but in case of ZFS it's not quite the same and in case of LAFS - not sure, but probably not the same either. With Merkle trees and log-structured FS it shouldn't be very expensive.