Hash Check on Update
With the issues at source forge for an example could the SVN installer run a quick check at the beginning confirming that the get command was successful before updating the local install.
[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.
Maybe adding a hash check to the troubleshooting script? Were we going to include the updated troubleshooting script in the utils folder for SVN.
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.
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:
So for instance:
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.
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)
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.
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.
I’ve recommended similar things. I think it’s not as simple as it may seem.