New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overwrite if the md5sum in a file is wrong but the content has not changed #8
Overwrite if the md5sum in a file is wrong but the content has not changed #8
Conversation
None of the Travis failures seem to have anything to do with my changes. |
…anged The code was reading the file, then generating an md5sum for the content and comparing it to the md5sum in the file itself. If these didn't match then it would return the _generated_ MD5 rather than what was actually in the file. It would then compare this generated MD5 to the MD5 for a regen of the same file. If they matched it would not bother writing the file. This works fine if it's the _content_ that has changed, but if the md5sum itself is wrong but the content has not changed, then returning the generated MD5 based on the content we just read is wrong. Instead, we now simply return a non-MD5 string. This will force the file to be written again whether it was the file's content that had changed or just its md5sum.
I just rebased this off the latest master. It'd be great if you could take a look at this. This bug has bitten us at $WORK a few times because of merges that end up changing the md5sum without changing the content. |
|
||
unlike slurp_file $foopm, qr/"somethingelse"/, "Modifications actually overwritten"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you intend to remove this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not. I'll have to take a closer look once I'm back home.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having had a closer look this morning, it's clear that that test should still be there, so I've reinstated it.
Sorry about the slow response. I've had a quick look, and it looks okay (modulo the comment on the test). I'll look at merging it tomorrow. |
Thanks for the fix, and your patience. I've merged it (with minor cleanups to the test) as 348abad. |
I'd greatly appreciate it if you could do a release with this fix. Cheers, -dave |
Done. Sorry for the delay. |
Thanks! |
The code was reading the file, then generating an md5sum for the content and
comparing it to the md5sum in the file itself. If these didn't match then it
would return the generated MD5 rather than what was actually in the file. It
would then compare this generated MD5 to the MD5 for a regen of the same
file. If they matched it would not bother writing the file.
This works fine if it's the content that has changed, but if the md5sum
itself is wrong but the content has not changed, then returning the generated
MD5 based on the content we just read is wrong.
Instead, we now simply return a non-MD5 string. This will force the file to be
written again whether it was the file's content that had changed or just its
md5sum.