Hash Check on Update


  • Testers

    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.


  • Testers

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



  • Sounds good.


  • Senior Developer

    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.



  • 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.


  • Developer

    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)


  • Senior Developer

    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.


  • Testers

    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.


  • Senior Developer



  • +1

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


 

473
Online

5.4k
Users

12.6k
Topics

118.9k
Posts