Fix testing/hashtest.py (#78)

[zjw]

This fixes and reenables the failing hash test identified in #78. Currently,
rdiff-backup only stores a hash with the first file in a series of linked
files. The test has now been modfied to recognize that fact.

Issue #78 also pointed out certain warnings that are generated about missing
SHA1 digests. It's believed that those warnings have already been fixed by
pull request #239.

[ericzolf]

Sorry, I can't accept this patch: the issue is not that the test expects a hash, the issue is IMHO that the functions RORPath.has_sha1/get_sha1/set_sha1 don't handle properly hashes for hard-linked files. The interface of the object should hide the fact that the hash is only stored once, and return transparently the hash of the first stored hard-link.

Given the fact that the test doesn't fail (because it's ignored), I don't see either the need for a temporary fix.

I only keep the PR opened if you have arguments I oversaw, but else I'd close it.

[zjw]

I don't dispute anything you said. However, the self-described purpose of this test_session(self) is:

Run actual sessions and make sure proper hashes recorded

The way the test accomplishes its purpose is that it opens the actual mirror_metadata file in order to inspect its contents and to assure that the hashes have been recorded as expected. The expected result is that there is a proper hash stored with the first file in a series of hardlinked files, but that no hash is stored with subsequent files in the series. So this test is focused on the contents of the mirror_metadata file. I haven't changed it focus -- It's just that the test was looking for the wrong results inside the file, and I have now corrected it.

Your issue is that RORPath.has_sha1/get_sha1/set_sha1 don't properly handle hashes for hard-linked files, and that these functions should transparently return the hash of the first stored hard-link. In other words, those functions should "just work" (regardless of any possible hardlinking). I agree; that would be nice. You also state that those functions should hide the fact that the hash is only stored once in the mirror_metadata file. Again, I agree. But this test case is not about any of that. This test is simply confirming that the mirror_metadata file was written correctly, and that is what the test does. You could make changes to RORPath.has_sha1/get_sha1/set_sha1 so that they "just work", and this test case would still function properly as-is, because it is looking at the underlying mirror_metadata file. So I do not see this as any sort of temporary fix.

This pull request also fixes a pesky issue with a binary string which should be committed, regardless -- thus possibly saving somebody the trouble of tracking down why that part of the code isn't working like it should.

[ericzolf]

The test isn't looking at the underlying structure, it's using xxx_sha1 which has the wrong interface IMHO and would fail if we'd change this. Where I can accept workarounds when they make the software work, I don't see the point where it's just making an additional, already skipped, test to work. Hence I'm closing the PR.