MUSHClient setup should not overwrite scripts, figlet files, or generally anything that hasn't changed, or that the user could have changed, at least not without prompting... I hate how it replaces the custom multiple_send.xml every time...
Mushclient setup suggestion
Posted by Poromenos on Fri 11 Apr 2003 11:26 AM — 10 posts, 33,927 views.
I think we went through this one a while back. You say it shouldn't overwrite things that the user changed - fair enough, but how do we know the user changed it?
Say the original file was installed in January, you changed it in February, and the new file (from the install) was changed in March. The installer looks at the file and says "I am replacing an earlier file, that is OK".
The only real way to know if *you* changed it would be to have a list of hashes for every file previously installed, and then hashes for the new ones, and warn the user if we appear to be replacing a file whose hash we don't know of. This could get quite complex if the MUSHclient files (eg., scripts) change quite often, but you don't necessarily install every version.
As for warning before replacing every file, that would be tedious. If you can give me an algorithm that you think would work (in pseudo-code) let me know.
Say the original file was installed in January, you changed it in February, and the new file (from the install) was changed in March. The installer looks at the file and says "I am replacing an earlier file, that is OK".
The only real way to know if *you* changed it would be to have a list of hashes for every file previously installed, and then hashes for the new ones, and warn the user if we appear to be replacing a file whose hash we don't know of. This could get quite complex if the MUSHclient files (eg., scripts) change quite often, but you don't necessarily install every version.
As for warning before replacing every file, that would be tedious. If you can give me an algorithm that you think would work (in pseudo-code) let me know.
Wouldn't it be possible to, in addition to the version that uses the installer, for each new release of MUSHclient also distribute a zip file that contains only those elements updated for that release?
Linda, the installer is very small, and the other files are too, so a zip file wouldn't really make a difference, maybe 30-40 kb?
Nick, about that suggestion, it's simple... Just update mushclient.exe and any DLLs or files that the user can't customize, and if the file dates are different for the rest of the files, ask. That way, if i changed a plugin, it would prompt me, otherwise it would overwrite/do nothing, because the files would be the same... NSIS can do that... Also, you should set "SetDateSave on" if you haven't, it helps.
Nick, about that suggestion, it's simple... Just update mushclient.exe and any DLLs or files that the user can't customize, and if the file dates are different for the rest of the files, ask. That way, if i changed a plugin, it would prompt me, otherwise it would overwrite/do nothing, because the files would be the same... NSIS can do that... Also, you should set "SetDateSave on" if you haven't, it helps.
SetDateSave is on, however I don't see how that helps. I still can't distinguish between a batch of files *I* have changed and a batch of files *you* have changed.
To anyone reading this, I recommend that if you plan to change a supplied file from the MUSHclient distribution (eg. sample script files, sample plugins, or whatever) you make a copy under a different name, and use the copy. That way it can't be overridden.
To be paranoid you would also put it into a different directory in case you choose a name I later use myself. This has the added advantage that you can tell which are your files, because they are in a different directory.
To be paranoid you would also put it into a different directory in case you choose a name I later use myself. This has the added advantage that you can tell which are your files, because they are in a different directory.
I wasn't suggesting a zip to cut down on size, just so you don't have to be concerned about files being overwritten. I'd just like to be able to extract only the files that were updated for that release.
Make it ask the user when the source file's date is different from the destination file's, except for mushclient.exe or the .dlls. With setdatesave on, the dates of the unchanged files of each release will be the same, so it would ask the user before overwriting files, even if you had changed them...
I think what Linda was suggesting, was having the installer create a subdirectory in MUSHclient, possibly named "Update", and extract all the files there. Then one could selectively copy the files from that directory, into the MUSHclient directory. This is assuming that the files to be copied don't have to be "installed" into the registery or integrated into another file somehow.
What Nick is saying is, when you edit a file, Rename it, that way it wont get overwriten, as well as you'll know that its YOUR file. There's no reason to make a 'smart installer' when you can just have smart operators. Cuts down on bloat, and makes things run more smoothly and clearly.