https://bugs.documentfoundation.org/show_bug.cgi?id=149106
--- Comment #17 from Mike Kaganski <[email protected]> --- (In reply to Samuel Mehrbrodt (allotropia) from comment #15) > (In reply to Mike Kaganski from comment #13) > > (In reply to Samuel Mehrbrodt (allotropia) from comment #11) > > > > RenamePrgFolder seems to be an immediate-execution DLL custom action. That > > means that it would run with user credentials (not scheduled for deferred > > elevated execution), and thus it would fail unconditionally when attempted > > to rename anything in Program Files (where normal user doesn't have writable > > permissions). > > Ah that makes sense. It worked fine for me when I tested this. Could it be that you have e.g. UAC disabled? That would allow logged in admin to avoid all the "do you want to allow the program ...?" questions, but at the same time, would hide the error - because the user credentials would allow the rename. > > Another failure (even if the action were ) could be when the renamed > > directory is being used; the normal MSI behavior in that case would be to > > have the new files copied to a temporary directory, and schedule a reboot to > > update the now-used files. But the action in question seems to try to do > > manually what should be done automatically. > > Any hints how that can be implemented (having files updated after reboot)? That does not require anything at all: it's how MSI works normally. I always was confused why OOo (and now LO) needed the custom actions at all ... The custom actions seem to try to duplicate the normal MSI functionality - and might themselves be a reason of some failures IMO. -- You are receiving this mail because: You are the assignee for the bug.
