mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Dear Santa,

For Christmas I would like an event that lets me monitor a file, or a set of files, for changes so that my script can re-initialize itself based on those changes. Like so:

Code:
On *:FILECHANGE:IgnoreFilters.txt: {
  var %file = $filename
  if (!$exists(%file)) { return }
  hfree -w IgnoreFilters
  while (...) { hadd ... }
}

ALIAS IgnoreFilters { run IgnoreFilters.txt }


Thank you, Santa!


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
Set up a timer that will check periodically if the file is changed or not.

I could be wrong but... how would mIRC know when a file is changed in order to trigger an event? mIRC as far as I know monitors changes only for scripts/ini files that are loaded and "in use" by mIRC itsself. Should it start monitoring all files in some predefined folders?


echo -a $signature
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
As a scripting language, Khaled can make it work however he wants to. That's what he does. I imagine that he would simply add the list of ON FILECHANGE filenames to his existing internal array of files to monitor for changes.

It is not for me to care HOW he does it. This is a feature request, not a bug report or a support request. I appreciate your enthusiasm to "help me", but not really.

One should appreciate the elegance of the thing, and not worry too much about anything else.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Feb 2009
Posts: 2
Z
Bowl of petunias
Offline
Bowl of petunias
Z
Joined: Feb 2009
Posts: 2
I second that notion.

Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
Dear Raccoon,

Im not trying to pick a fight with you. Im merely trying to understand what way your suggested feature is supposed to work, in order to know if I would find it to be something that I would also want to see implemented or not.

As for you being the person who makes the suggestion you should care about the "HOW", and also I imagine that you have at least some vision about the feature you are suggesting.

My "enthusiasm to help you" was merely pointing out that scripting engine lets you achieve this functionality already. So it is more or less a question "why is this not enough / why would other way be better / why it needs to be 'hardcoded'".

And yes I am aware that this is a feature request, not a bug report or a support request... but does this mean that I'm not allowed to voice my opinions about the Feature Suggestion?

Santa
Brax smirk


echo -a $signature
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
The existing functionality of using a timer would be vulnerable to "/timer* off". Also, using the existing timer functionality to replicate the same monitoring that mIRC does for its own ini's and scripts would probably involve running a -h multimedia timer with a very short interval, as evidenced by how rapidly the Initialization Warning pops up when you alter the timestamp of a loaded remotes script. I assume that using a multimedia timer to replicate this taxes mIRC's resources much more than if this were an event.

On *:FILECHANGE:c:\path\Ignore Filters.txt: { }

It shouldn't be a problem to have the filename include a colon, as the following slash identifies it as part of the filename instead of the end of the event header. There shouldn't be a need for double-quotes around a filename containing a space.

Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
Fair enough.


echo -a $signature
Joined: Nov 2004
Posts: 842
Hoopy frood
Offline
Hoopy frood
Joined: Nov 2004
Posts: 842
Originally Posted By: Brax
how would mIRC know when a file is changed in order to trigger an event


CRC32 checking?


What do you do at the end of the world? Are you busy? Will you save us?
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
It would likely check for change the same way that Initialization Warning checks, by looking only at timestamp date, and not filesize or contents. As mentioned here:
https://forums.mirc.com/ubbthreads.php/topics/261645/mIRC_reload_scripts_warning#Post261645

Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
Thats not what I meant. I probably didn't say it right.

What I meant was how will mIRC start monitoring the specific file in first place to be able to trigger the event when the file changes.

--

Trying to answer it myself --- perhaps similar to sockets?
Something like first creating listener with /filewatch <name> <file> and then using On 1:FILECHANGE:name:commands

---
Edit:
Originally Posted By: maroon
It would likely check for change the same way that Initialization Warning checks, by looking only at timestamp date, and not filesize or contents.


I sure hope not. Because then additionally for mIRC getting all confused about loaded scripts twice a year (when DST comes in effect and ends) it would also start giving false change notices for the files you monitor as well.

Last edited by Brax; 29/11/17 06:37 PM.

echo -a $signature
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
I don't think it would even need a /filewatch. It could do it the same way it does now with 'how does it know to monitor a channel for the text event !help. When a script is saved, it can scan the file for an on-filechange event, and add the cited filename to the stable of files being watched.

Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
Ah okay.

Perhaps I have then misunderstood the principe how the events work.
I always thought that it doesnt "monitor" a channel just because you have an event listener in the scripts.
So text would be data being sent by server and mIRC "monitors" everything that server sends to it, parses it, sends to specific window and also exposes it to scripting engine by triggering ON TEXT event regardless if there is a script that wants that ON TEXT or not.


echo -a $signature
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
Something like first creating listener with /filewatch <name> <file> and then using On 1:FILECHANGE:name:commands

Yes, a /filewatch would be required. mIRC only parses events when something triggers them, it does not create triggers out of events.

Quote:
It would likely check for change the same way that Initialization Warning checks, by looking only at timestamp date, and not filesize or contents.

Yes, it would use exactly the same method since it would be using the same routines.

The use of a CRC check has been discussed before but it would not be practical. If someone has a large number of scripts loaded, this would result in a freeze every time mIRC had to scan all loaded scripts, eg. at startup, whenever you edited a script, or during file change notifications, since a CRC check would take time to perform. A file time check, on the other hand, is instant and, although there may be some outliers, is generally satisfactory.

Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
Originally Posted By: Khaled
Yes, a /filewatch would be required. mIRC only parses events when something triggers them, it does not create triggers out of events.


Thanks for clearing it up.

As far as the suggestion itsself goes - yes I personally can see quite a many use cases for it. Script settings file being one of many as Raccoon already points out in the title of this topic. Getting ability to have constant monitoring of specific files in realtime would make some things easier.

Originally Posted By: Khaled
The use of a CRC check has been discussed before but it would not be practical. If someone has a large number of scripts loaded, this would result in a freeze every time mIRC had to scan all loaded scripts, eg. at startup, whenever you edited a script, or during file change notifications, since a CRC check would take time to perform. A file time check, on the other hand, is instant and, although there may be some outliers, is generally satisfactory.


I don't mean to hijack this thread for another suggestion but wouldn't it be viable to add at least DST to the existing routine to supress the pointless warnings twice a year when DST changes?

Seeing as mIRC already can tell if DST is in effect or not ($daylight) it seems like something doable if you store the seconds offset along with the timestamp and suppress the warning if the timestamp changes together with the DST offset (Or check specifically if the amount of change is the same as changed seconds offset.)


echo -a $signature
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
I would call that a separate bug for a separate thread. The DST bug is real, and should be addressed independently. I expect it's a matter of two time-calculation methods or APIs conflicting, possibly as minor as an off-by-one error.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
The DST bug is difficult to resolve reliably. Here are some of the variables that need to be taken into account that can affect the results of retrieving a file time: different APIs can return different results, different runtime functions can return different results, state of the TZ environment variable can affect results, different versions of Windows and WINE can return different results, bugs in different versions of runtime/API calls need to be taken into account, FAT/NTFS can return different results, quirks such as GetFileTime reading from a UTC cache that only gets reset when Windows is restarted, and so on.

To get around all of these DST-related issues, most backup applications have a simple "DST" option that ignores file time changes that occur exactly one hour before or after. Some backup applications actually have several options just to handle DST to different tolerance levels but few of them attempt to resolve the issue on a technical level. The latest mIRC beta ignores file time changes one hour before or after - which should resolve the twice yearly issues that users report - but at the expense of not correctly detecting file time changes exactly one hour before or after.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Khaled: In addition to what you said above, does the file monitoring routine now check against time AND filesize changes, or does it check for time OR filesize changes? I'm hoping the latter, making it more sensitive and not less sensitive.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
I know this is a somewhat late post to this thread, but this does sound like a useful function.

Windows itself provides watching functionality, so:
Code:
/filewatch C:\Temp\ignore.txt

would only need to add that file to Windows own watching functionality - it would not need to periodically check timestamps or CRCs.

If windows reports a file change, then it could trigger an ON FILECHANGE event.
Code:
ON *:filechange:mask: commands

where mask is (like other such events) a way of making only certain filespec's trigger the event (like e.g. *.txt)

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Originally Posted By: Protopia
Windows itself provides watching functionality,... it would not need to periodically check timestamps or CRCs. If windows reports a file change, then it could [just] trigger an ON FILECHANGE event.


I wrote this feature suggestion on the assumption, which I still presume to be correct, that mIRC is already utilizing this Windows' functionality... whether file-by-file or on whole directory trees.

The reason that mIRC currently does perform time-date and file-size comparisons is because some activities can be perceived as modification to a file but really isn't, or that some files mIRC does watch are allowed to be changed, within reason, without actually triggering a change has happened.

I don't claim to know all the particulars, there are a lot of approaches, but suffice it to say that the framework exists. It does utilize Windows API (as far as I can tell).


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Ah yes - I had forgotten that mIRC has a script auto-reload capability.

Assuming that Windows reliably informs when a file changes (even if it is e.g. only a last access timestamp change), then it would make sense for mIRC to check the size and last modified timestamps to see if they have changed when Windows informs mIRC a change has occurred.

And I couldn't imagine that Khaled would implement this feature without using that.

Page 1 of 2 1 2

Link Copied to Clipboard