Hash Check on Update

[Wayne Workman]

+1

I’ve recommended similar things. I think it’s not as simple as it may seem.

[Joe Schmitt]

Use git.
[url]https://github.com/FOGProject/fogproject[/url]

[Joseph Hales]

Getting the installer isn’t the issue, the issue is when the installer is run and it gets components and inits and some of the files fail to transfer we could use a more obvious error message and perhaps a prompt to try and fetch again or roll back any changes. I agree it is a nontrivial task but it would solve a reoccurring issue.

[Joe Schmitt]

We’re actually hoping to move away from sourceforge for hosting the kernels & inits, and host it our self. But I do agree that we should hash check them.

[Junkhacker]

this is something that Tom and I have investigated before. we wanted to; query for the hash, download the file, compare hash. but, sourceforge doesn’t make it as easy to query the hash for a file (at least we couldn’t figure it out in the time we spent on it. if you know how to do so reliably, please let me know)

[Wayne Workman]

I say…

this… (just my two cents, I used to develop heavily)

Build a script that recursively goes through every file in a new “revision” and makes hashes for them.

Stick all hashes into 1 text file. Perhaps in this format:

<Hash> <filepath>

So for instance:
abcdef1234567890 /such/n/such/kernel

Then,
make that file part of the revision.

That file should be the first downloaded.

When the old version of FOG gets moved to the fog.prev folder, it’ll have the old hashes.

IF the old hashes match the new hashes, then [B]no download is necessary[/B].

If the old hashes don’t exist, then download. After downloading, compare the hash of the file downloaded to the stored hash. If they match, you’re good. if not, re-download.

If the old hashes don’t match the new hashes in the file, download, then check the download as above.

[Joe Schmitt]

Just to throw in my 2 cents:

We do plan on hashing and skipping existing kernels/inits.
However, in general you do not want to pre-hash files. Why? Because users can update the files themself. A more efficient way of doing it, is to hash the kernels/inits in the dir on install & then check with our server if that hash is up-to-date.

[Wayne Workman]

Sounds good.

[Joseph Hales]

Maybe adding a hash check to the troubleshooting script? Were we going to include the updated troubleshooting script in the utils folder for SVN.

[Wayne Workman]

[quote=“Joseph Hales, post: 47440, member: 18131”]Maybe adding a hash check to the troubleshooting script? Were we going to include the updated troubleshooting script in the utils folder for SVN.[/quote]

Now that’s a winner. Let ya know if your FOG files are busted or not.