For maximum confusion, Helicon names its configuration file httpd.conf like Apache. I made some modifications to the logging verbosity in that file, helping out an admin who hadn't realized that debug-level verbosity on redirect logging results not just in poor performance from the additional overhead needed to write to a file each time a URL is mod'd, but in a huge file that will quickly overwhelm available storage. Attempting to save http.conf resulted in errors because it was in use by a process so I copied my modified file to the desktop, renamed the existing conf file and copied my copy back into the Helicon configuration directory.
My changes weren't applied. The syntax was correct in my changes and Helicon kept processing redirects. Sure enough I compared permissions on the two files and the NETWORK service user had been stripped from my modified file. Propagating the correct permissions allowed the file to be read and the changes applied.
My complaint: helicon continued to run without access to the file, so why is a process lock required? Let me modify my files and deal with the consequences. As an aside, I highly recommend Unlocker, a lightweight application that overrides overzealous process locks and comes with an available and invaluable addition to your right-click context menu.