Checksums for Troubleshooting

Discussions around using and interfacing with the Church MLS program.
atticusewig
Member
Posts: 308
Joined: Fri Jan 19, 2007 9:48 am

Checksums for Troubleshooting

Postby atticusewig » Mon Jun 28, 2010 7:39 am

Many times on the forum we hear about how some MLS problem
or other is fixed by reinstalling MLS from the executable available
online. This often involves a visit to mls.lds.org site (and knowledge of
the appropriate password), and a sizable download. I propose an
easier solution - checksums.

Basically the church decides on checksum program (something user
friendly and able to use a list of checksums for comparison) that is
part of the Additional Software that is installed on the computer.

When a new version of MLS comes out, a list of checksums for the
program files of MLS are sent down the line. As an added precaution,
the checksums are added to a locked page on the wiki.

Whenever there is a problem, a user can run the checksum program that
will identify which files, if any, are corrupt. Then he can take a flash drive
to another clerk's office, and ask if he can get a copy of that unit's non-corrupt file. Kinda like borrowing a cup of sugar from your neighbor.
He then can use that copy to overwrite the corrupt file on his computer,
and viola - MLS is working again.

Once in place it seems like a simple solution to me, but let me know if you
can see anything I'm overlooking.

- Atticus

lajackson
Community Moderators
Posts: 6129
Joined: Mon Mar 17, 2008 9:27 pm
Location: US

Postby lajackson » Mon Jun 28, 2010 7:55 am

atticusewig wrote:Many times on the forum we hear about how some MLS problem or other is fixed by reinstalling MLS from the executable available online. This often involves a visit to mls.lds.org site (and knowledge of the appropriate password), and a sizable download. I propose an easier solution - checksums.
. . .
Once in place it seems like a simple solution to me, but let me know if you can see anything I'm overlooking.


This would work as long as the corrupted file is a basic part of the program. If it is one of the files that then gets modified to contain specific unit information, there may be a problem.

But the theory is good. And one little file is a whole lot easier than one big 100+ meg file, as long as you are careful in drilling down through the directory structure.

I have just gotten to the point where I keep the latest full load on a flash drive. Although with all the hubbub this weekend, I might just keep the beta around a bit longer. It seemed to work just fine. [grin]

User avatar
aebrown
Community Administrator
Posts: 14685
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Mon Jun 28, 2010 9:50 am

atticusewig wrote:Whenever there is a problem, a user can run the checksum program that will identify which files, if any, are corrupt.
...
Once in place it seems like a simple solution to me, but let me know if you can see anything I'm overlooking.


I suppose there's a chance that this could be helpful, but at this point, I have seen no evidence that the underlying problem is a corrupted download. That doesn't mean that corrupted downloads are not necessarily a problem, but before we try to create a solution, it would be nice to have some evidence that it is indeed the problem.

It seems to me that there are a variety of other potential sources of the problem, none of which would be fixed by a checksum:

  • Failure to download a required patch file.
  • Error while deploying a patch file.
  • Faulty logic in a patch file.
Installing a full download seems to be executing different code from applying an incremental patch, so there are many opportunities for it to work differently. A corrupted download seems to me to be a fairly unlikely option. But if someone can verify that it is indeed a common problem, then a checksum mechanism might be helpful.
Questions that can benefit the larger community should be asked in a public forum, not a private message.

atticusewig
Member
Posts: 308
Joined: Fri Jan 19, 2007 9:48 am

Postby atticusewig » Mon Jun 28, 2010 11:41 am

The point of the checksum would not be to check the download for
corruption, but the MLS program files for corruption.

If a patch wasn't downloaded or applied, a checksum would show whether or
not a particular program file like mls.jar matches the mls.jar of a working system.

Granted, data corruption errors would still require the assistance of CHQ,
and programming logic errors - such as the suggestion that a really large logfile
isn't handled properly by the software in its uncorrupted form- would still be
in need of correction.

Moving the discussion forward, can anyone suggest a good and free win32
checksum program that can give the functionality as described ?

russellhltn
Community Administrator
Posts: 20729
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Mon Jun 28, 2010 3:10 pm

atticusewig wrote:The point of the checksum would not be to check the download for
corruption, but the MLS program files for corruption.


Yes, but how many times is the problem caused by a corrupt or missing program file? While we may find it a convenient scape goat in explaining why a reinstall fixed things, I have my doubts about the accuracy of that claim. In addition to the files, there are registry entries, data files and install procedures that may have failed. Furthermore, I suspect that in many cases the patches do not contain a updated Java engine while the full sized files do.

On top of that, we need to see if simply copying files will actualy fix a failed patch/install, or if we'd just be spinning our wheels.

Personally, I think this carries more time and risk then possible benefit.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.


Return to “MLS Support, Help, and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest