![]() ![]() 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. Then mIRC should check to see if the timestamp OR FILESIZE has changed. ![]() 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. ![]() It's dumb, but it's still a change in the non-content portion of the file.Ī better way to implement it, and one that mIRC should do, is have a 2-step check system. It's not a change in file contents, but it is a change in the timestamp attribute of the file. I, like a huge number of people, got tired of getting the warning (15 scripts loaded usually means you get 15 prompts whenever this is happening, sorry but no thanks) and just disabled the feature, it's possible to write a script which use an hashing if you are talking about looping on $script and using /reload, that's not going to be helpful because the events which are causing all of this are unknownĪ change in 'last modified time' does not equal a change in file, technically speaking users are completely right and you're completely wrong. To me this feature is just broken as it does not check file for change but claims there is a change in file when there's only a change in "last time modification'. The reason for this was that because it takes time to calculate such hashes, and that mIRC might be checking a lot of files, so it would prevent a possible slowdown in this case. This issue has been reported before, mIRC does not use a hashing algorithm to make sure the file changed. It's not "no reason"a change in 'last modified time' does not equal a change in file, technically speaking users are completely right and you're completely wrong. ![]()
0 Comments
Leave a Reply. |