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

[Sean Hall]

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/
>