That's correct; When IIRF cannot open the IIRF.ini file, after it had already successfully opened the IIRF.ini file, IIRF reverts to the "last known good" configuration. I don't know if this is documented behavior, but it is as designed. The reason for this is that when an ini file is being updated, There is a race condition and in some cases IIRF will fail to open a file that really exists.

As it is today, If you want to wipe out a configuration, you need to "empty" the IIRF.ini file - remove all the rules and save the file with no rules in it - but not delete the IIRF.ini file. You can also add a line that reads "RewriteEngine OFF" to the IirfGlobal.ini or to the local IIRF.ini.

I'll have to think about whether I think the current behavior is a bug or not. Right now I think the current behavior is not a bug, but I'm open to hearing persuasive arguments on that.

I've experienced many cases where a client wants to revert the situation of a website to default and part of that is deleting the iirf.ini-file, which unfortunately in that situation does not result in what one would expect (even though I can relate to the design). Also, for many it would be expected behaviour to be able to delete the iirf.ini file to clear out any active rewrite rules (for example when being used to .htaccess).

Perhaps it's an idea for IIRF to check for the difference between when a file is deleted or an access violation if such a thing is possible? In case of an access violation I ifcourse vouch for IIRF to cache the already applied rules as it does now.

I think your view is a reasonable one. It is expected behavior that deleting the ini file will clear any configuration. I need to make that change.