Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Bug reports ➜ exampscript.*

exampscript.*

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by Dave   Australia  (93 posts)  Bio
Date Sat 11 May 2002 04:08 AM (UTC)
Message
For one of my worlds, I was lazy and simply used exampscript.jvs as my world file, instead of making a new file. When upgrading to the latest MUSHclient however, the script was overwritten with the "new" exampscript.jvs, killing all the work I had done in the script. Unfortunately, I didn't have a backup.

Could you perhaps add checksums to the exampscript.*'s on future versions, and when updating, if it doesn't match the previous versions' checksums, you know it has been edited and it should prompt a replace confirmation?
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #1 on Sat 11 May 2002 07:29 AM (UTC)
Message
Simplest way to do this would be to make the installer let you customize what it lets you install... Oh wait... IT DOES!!!

While I sympathize with your loss I feel the need to point out that using Typical or Custom with 'all' items selected to install the client automatically 'assumes' you have a clue and that you want to replace those files. The option is available to choose custom install and deselect the example files.

There may be ways to have the installer check anyway, but they rely on 'system awareness', which means the system registry would need to know about the files and have a way to show they changed, or extra and maybe even outdated and redundant info stored in the installer. In the case of the registry... Gammon is trying to get rid of the need for that, since it limits where and how you can use the client. It isn't practical for the installer to check and/or second guess the person installing it. The typical install could be set to 'not' install the examples, but that is not generally the expected or wanted result. In most cases such things are excluded in typical installs only if they take up very large amounts of disk space.

You goofed. It is as simple as that. Which reminds me... Better make a backup of the new changes in mine soon. :p
Top

Posted by Dave   Australia  (93 posts)  Bio
Date Reply #2 on Sat 11 May 2002 08:41 AM (UTC)
Message
Well it wouldn't be hard to recognise whether or not an exampscript is one that was distributed with a previous version of MUSHclient or not. If it's been changed, pop up a message letting the user know that it's going to overwrite a non-standard MUSHclient file.

As far as "goofing" goes, I didn't really think about it at the time, I figured some sort of implementation of this would have been in place.

People are going to use exampscript's, because it's the default script file, so having a mechanism that establishes whether a previous exampscript has been modified or not isn't at all unreasonable, and people shouldn't have to resort to doing "Custom" installs to bypass it.
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #3 on Sat 11 May 2002 06:59 PM (UTC)
Message
Well the problem come down to 'how' do you tell if it isn't. The methods are:

1. Have the system keep track of it (requires the installer to reboot and uses system registry, so bad idea).

2. Have the installer actually know the contents of the file. This is really not something you wan it to do, since it is bad form.

3. Use a calculated check-sum. Unrealiable in that it is 'possible' for it to still produce a checksum that is the same as previous versions of the files and the odds increase a lot as more and more 'different' sample files need to be kept track of.

4. Date and time of creation. Bad idea, since the last time you updated the file could easilly be the same day and even by pure chance time that some new version is made. Then this istall may not eat it, but the next one may.

The 'only' method that works well is to imbed a version number in files that may be replaced and have the installer check the version number against the new install. This 'only' works for binaries, since not deleting the version info from the file is basically the same as not changing the name, it will still see it as the same file.

I suppose 5. Check file size woud also work, but then you could delete a chunk of the example code and then accidentally add back in the exact same number of characters you removed.

There is really no practical means to verify the state of a text document with any real precision, let alone automatically detect if they are changed. The best bet would be for Gammon to make new installs have 'install examples' off by default, but for files that are as small as they are, there is not a lot of point in most peoples cases for doing that.
Top

Posted by Dave   Australia  (93 posts)  Bio
Date Reply #4 on Sun 12 May 2002 01:07 AM (UTC)
Message
Why wouldn't checksums work? MD5, for example, uses a 128bit hash, or 340,282,366,920,938,463,463,374,607,431,768,211,456 (three hundred and forty undecillion) possible combinations. It's relatively safe to assume collisions won't happen too often. :P
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


15,533 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.