a change in 'last modified time' does not equal a change in file, technically speaking users are completely right and you're completely wrong.
I'm wrong, but I'm not completely wrong. It's not a change in file contents, but it is a change in the timestamp attribute of the file. It's dumb, but it's still a change in the non-content portion of the file.
A better way to implement it, and one that mIRC should do, is have a 2-step check system. mIRC could store the timestamp of the file like it currently does - but should also record the filesize and the hash of the file at that time. Then mIRC should check to see if the timestamp OR FILESIZE has changed. However, instead of immediately displaying the change warning that the file has changed when only the filetime has changed but not the filesize, it should then check to see if the hash has changed, and display the change warning only if the hash has also changed. If the hash didn't change, mIRC should just update its saved time/size/filename for that script and move on.
The current method does have a bug because it checks ONLY the filetime and ignores the filesize. This causes mIRC to report a false positive when only the timestamp changes without the contents changing, such as the transition on/off daylight saving time - but also causes mIRC to have a false negative when the contents change without changing the timestamp.
TO REPLICATE THIS BUG:
0. Make sure that "Monitor File Changes" is enabled in the Remotes Script Editor.
1. Take any of your loaded scripts, and make note of the timestamp. For this example, I'll assume the filename is script1.mrc
2. Create a DUMMY folder and copy versions.txt
3. Using a utility which lets you alter the timestamp of a file to a specific time, change the timestamp of the copy of versions.txt
to match the timestamp of your script1.mrc, including making sure the the seconds match.
4. Copy the clone of versions.txt
on top of the test script script1.mrc and you'll see that mIRC does not give a warning even though the filesize has suddenly changed to 600kb. It doesn't matter whether you use a file manager to do the copying or use "copy -o DUMMY\versions.txt
script1.mrc" to replace the contents, there will be no warning if the timestamps match exactly. If at that time you use Alt-R to load script1.mrc into your editor, you'll see the old contents displayed and not versions.txt
, because mIRC hasn't determined that a change has occurred.
mIRC's check for the filename is case-insensitive, so using "cmd /k ren script1.mrc SCRIPT1.MRC" will change the case of the script file without generating a warning. I don't see this as a problem - as long as a verification of the hash is made at that time. Even utilities which warn about file changes will allow you to have the option to ignore timestamp differences which are exactly 1:00:00 hour different likely caused by a timezone change, or the timestamp's odd number of seconds altered by being saved into a .zip which keeps only the DOS timestamp that always saves the timestamp with the seconds being even.
In Summary, current behavior is:
if (%saved_timestamp-made-at-alt_r-saving != $file(filename).mtime) Do_Warning
To avoid unnecessary hashes at frequent intervals while still having better warnings of file-content changes, behavior should change to:
if (%saved_filesize != $file(filename).size) goto Display_Warning
if (%saved_filename !=== $nopath($file(filename).longfn)) goto hash_check
if (%saved_timestamp != $file(filename).mtime) goto hash_check
return ; (do nothing)
if (%saved_hash != $sha256(filename),2) goto Do_Warning
set %saved_filename $nopath($file(filename).longfn)
set %saved_timestamp $file(filename).mtime
return ; don't display warning
If mIRC also wanted to have an additional check of script hashes regardless of identical timestamp or filesize, that could also be an added layer of verification that's done at some regular interval such as hourly. Doing it at the time the Remotes Script Editor opens is probably not a good idea, as it would impose a delay while all N scripts are hashed.