Plugin Manager - N++ does not restart on installing a plugin

  • cchris

    cchris - 2014-02-23

    I just tried to use PluginManager on my office machine (Win7/94 pro unprivileged with a few extra group policies). Download takes place, I'm asked to allow reload. I say yes, and then nothing happens. N++ and the manager dialog remain open and otherwise function normally.
    phe Plugin_manager_temp newly created folder has a plugin1 subfolder the downloaded file and a dow9BA9.tmp file.
    Our office boxes have a number of security measures enacted by group policy, so there is no overriding them.

    It would seem that the plugin contemplates two use cases only: install in %programfiles%, in which case elevation is resquired, and %appdata%, where it is not needed. In the case at hand, we install on a different drive, and Plugin Manager thinks it needs to run as admin, which is prevented.

    Perhaps the right thing is to add an option not to run elevated no matter what.

    Installling the plugin manually works fine, thanks.
    Any advice?

  • Dave Brotherstone

    This "third case" is definitely an issue. A known issue, but an issue non-the-less.

    I have a plan to fix gpup.exe, so that it starts as the standard user (non-elevated), then attempts to copy the files. If that fails with access denied, then it attempts to start itself again with elevated permissions. Once the file copy is complete, this elevated process then completes, returning to original non-elevated process. The non-elevated process then restarts N++.

    This solves the "third case" by checking if files can be copied without elevation, but more importantly means that N++ is restarted with the same level of elevation as it was originally started (ie. start as normal user, after restart from gpup.exe, still normal user, but start as admin, restart from gpup.exe, still elevated).

    No idea when this will be, but that's the fix/plan.


  • cchris

    cchris - 2014-02-27

    Thanks Dave for the reply and future fix. I was thinking that the simplest thing to do /in theory/ is indeed to try without elevating first, and request privileges only if needed.

    For the time being, the workaround I found (after inspecting the code) is to temporarily rename doLocalConf.xml so that gpup.exe thinks it will use %appdata% and won't try starting elevated. The workaround works, at the cost of extra file manipulation by user.


    • Dave Brotherstone

      Renaming dolocalconf.XML shouldn't have any effect, as that only changes
      where the plugin config is stored, not the plugin itself. Gpup needs
      elevated permissions to copy the DLL, at least in the standard case. Using
      allowAppDataPlugins.XML (I might have the name wrong) will allow PM to
      install the plugins themselves to appdata.