Oxide attempts to compile a plugin while it is being written to the disk. This results in an unexpected end of file error. This is not a noticable problem on a local/LAN host. However, it is apparent when updating plugins on a remote server. The workaround is to overwrite the updated plugin a second time, but this is cumbersome and complicates the process of updating multiple remote servers.

I believe that correct behavior is to wait for the updated file to be closed before attempting to compile/load the plugin.

Oxide listens for file system changes from the system, it isn't monitoring those files manually. Trying to load files a second time wouldn't necessarily be reliable, and I've only seen this less than a dozen times and primarily on Linux servers.

Unlikely to be resolved with Oxide though due to the compiler not really be touched with it. Either way, the compiler in uMod is different and may not be an issue with it.

Yes, the problem appears on Linux servers. The system is triggering a file change notification prior to the write being completed, which is normal.

I do not believe that this is relevant to the compiler, but I do believe that is is relevant to the listener. "Writing" the file a second time triggers another file change notification, but this time the file contents are completely written to the disk, and the compiler has no issues with this second attempt to compile the plugin.

If there is a second notification, it should be attempted to be loaded again; if not then might be something that could be changed.

I think this PluginLoader debug line is a symptom of the second notification, meaning writes are still occuring.

(16:40:46) | [DEBUG] Reload requested for plugin which is already loading: Guardian
(16:40:47) | Error while compiling: Guardian.cs(9054,4): error CS1525: Unexpected symbol `end-of-file'

FSWatcher sends the second change notification , but the compilation has already been queued on an incomplete version of the file.

"Writing" the file a second time, after the compiler errors out, works because the file is intact (and the queue is empty) at that point.