[wix-devs] [wix-users] WiX 3.10.1 failing to update to 3.10.2

[Sean Hall]

Assuming that Bundle A is doing an UpdateReplace with Bundle B, the
unelevated bundle A (which would be the clean room Bundle A if built with
v3.10.2 or later) launches Bundle B and then calls WaitForInputIdle with a
max timeout of 5000ms.  Untrusted Bundle B starts up Clean Room Bundle B.
Since Untrusted Bundle B never starts a message loop, Bundle A is always
going to wait the full 5000ms of its WaitForInputIdle call.  Before the
clean room, the WaitForInputIdle call would normally return earlier since
there are multiple message loops in the process with the BA.

On Sun, Mar 6, 2016 at 12:32 AM, Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> But now we have these"other" processes in the mix. If a launches
> speedib at phukit.net launches c (update cr), what is telling a to wait for
> c?
>
> Sent from my PHONE
>
> > On Mar 4, 2016, at 7:52 PM, Sean Hall <r.sean.hall at gmail.com> wrote:
> >
> > It might technically be a race condition, but the executing engine is
> > calling WaitForInputIdle with 5000ms and the engine grabbed the handle
> > right away so realistically it wasn't a problem.
> >
> > Since the deletion code is in the older bundle, we can't fix that now.
> > Also, changing how the engine handles downloading and executing updates
> > seems to be outside the scope of v3.10.3.
> >
> > Is anyone working on getting the clean room engine to grab a handle to
> the
> > original bundle?  I should still have my test projects from working on
> that
> > issue with updates a while ago, so I should easily have time to knock it
> > out this weekend.
> >
> > On Fri, Mar 4, 2016 at 4:52 PM, Hoover, Jacob <
> Jacob.Hoover at greenheck.com>
> > wrote:
> >
> >> Aren't we getting into a race condition here, where we are just lucky
> that
> >> the update bundle was able to acquire a handle before the original
> bundle
> >> performed cleanup?
> >>
> >> To me, it would be better if the initial bundle placed the update bundle
> >> in the local cache (per user) under its appropriate ID based folder.  If
> >> the user by chance aborts the update bundle installer, it should
> schedule
> >> itself for deletion after it move itself to the temp folder (if it's
> >> running from the cache).
> >>
> >> -----Original Message-----
> >> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf
> >> Of Rob Mensching
> >> Sent: Friday, March 04, 2016 1:31 AM
> >> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> >> Subject: Re: [wix-devs] [wix-users] WiX 3.10.1 failing to update to
> 3.10.2
> >>
> >> I've been thinking about this and I have a theory what broke.
> >>
> >> Prior to v3.10.2 and the clean room, the code to cache files from the
> >> attached container used a file handle that was opened very early in the
> >> process. I explicitly remember commenting on the removal of that code
> when
> >> reviewing the clean room because it seemed like a really minor
> >> optimization. As the code was written, using the handle wouldn't work in
> >> the clean room (because clean room process doesn't have the container
> >> attached) so the optimization was removed.
> >>
> >> So my hypothesis now is that optimization was what allowed updates with
> >> attached containers to work. Goes something like this in the code before
> >> v3.10.2:
> >>
> >> 1. A handle was opened to the updated bundle itself early in its start
> up.
> >> 2. Old bundle tried to delete the file but found it was in use so moved
> it
> >> to the temp folder and scheduled for deletion on restart.
> >> 3. Updated bundle needs file from attached container, uses handle it
> >> opened in step 1.
> >> 4. Everything works if though the file name for the handle changed in
> step
> >> 2.
> >>
> >> So, one fix might be to bring back the opening of the handle code in the
> >> clean room, and use that for attached containers, much as code did
> >> pre-v3.10.2.
> >>
> >> _______________________________________________________________
> >> FireGiant  |  Dedicated support for the WiX toolset  |
> >> http://www.firegiant.com/
> >>
> >>
> >> -----Original Message-----
> >> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf
> >> Of Sean Hall
> >> Sent: Thursday, March 3, 2016 1:17 PM
> >> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> >> Subject: Re: [wix-devs] [wix-users] WiX 3.10.1 failing to update to
> 3.10.2
> >>
> >> I also don't know how we should fix this in v3.10.3.  The 3.10.2
> bundle's
> >> Burn engine is the one deleting the 3.10.3 bundle.  So either we find
> out a
> >> way for 3.10.3 bundles to block the immediate deletion (somehow lock the
> >> file, at least until the parent bundle waited the 5 seconds?), or we
> would
> >> have to copy the full bundle to the clean room.
> >>
> >> ____________________________________________________________________
> >> WiX Toolset Developer Mailing List provided by FireGiant
> >> http://www.firegiant.com/
> >> ____________________________________________________________________
> >> WiX Toolset Developer Mailing List provided by FireGiant
> >> http://www.firegiant.com/
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>