Squirrel.Windows
Squirrel.Windows copied to clipboard
Squirrel
Failure when 2 apps run Squirrel's auto-updater/installer
Hi guys,
I have an issue:
- The 1st application use Squirrel's auto-updater/installer, and this app is running normally
- I also have a 2nd application also use Squirrel's auto-updater/installer.
- There are no problem in case of install 2nd app without running the 1st app.
- When the 2nd application is installing, at the same time the 1st app is running, this app got an error: The process cannot access the file '%localappdata%\Temp.squirrel-lock-...' because it is being used by another process.
I think the Squirrel's auto-updater/installer got a deadlock when try to use '%localappdata%\SquirrelTemp' dicrectory
If any one got a same issue and has a solution to fix, please let me know! Thank you so much!
@SeaweedNguyen apologies for the delay in replying.
Looks like this is the problem path:
https://github.com/Squirrel/Squirrel.Windows/blob/611422cb0c27d2f8d497c710d545086dc2b4e857/src/Squirrel/Utility.cs#L822
But key is being derived from the hash of the path:
https://github.com/Squirrel/Squirrel.Windows/blob/611422cb0c27d2f8d497c710d545086dc2b4e857/src/Squirrel/UpdateManager.cs#L270
Which is extra strange because it looks like both code paths that set rootAppDirectory in the constructor are using applicationName, so they should be distinct:
https://github.com/Squirrel/Squirrel.Windows/blob/611422cb0c27d2f8d497c710d545086dc2b4e857/src/Squirrel/UpdateManager.cs#L44-L49
This might have been inadvertently fixed by some other issue, given how UpdateManager is at the core of a bunch of things in Squirrel, but can you confirm two things:
- which version of Squirrel this was occurring in
- which application (the one installing or the one updating) is the one that actually received the error?
When the 2nd application is installing, at the same time the 1st app is running, this app got an error:
I also worry about there being two attempts to update the first app that triggers this, which is a valid reason to throw, but there's no logs or further information to investigate that side of things.
Same issue here, I think. I have an in-house app built with Squirrel v1.9.1, and we've just started deploying MS Teams automatically.
On new-build machines the installers/updaters for both seem to get in a tangle and try to work in each other's way.
My app is called SkypeTelemetry and is installed into %localappdata%\SkypeTelemetry, but when the Teams installer runs it tries to hook into a munged path combining the Teams path (which should be %localappdata%\Microsoft\Teams) with my app's path and tries to update %localappdata%\Microsoft\SkypeTelemetry which doesn't work:
2019-10-11 15:20:26> Program: Starting Squirrel Updater: --install . --checkInstall --silent
2019-10-11 15:20:26> Program: Starting install, writing to C:\Users\bmtest\AppData\Local\SquirrelTemp
2019-10-11 15:20:26> UpdateManager: using rootAppDirectory: C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry
2019-10-11 15:20:26> Program: About to install to: C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry
2019-10-11 15:20:26> Program: Setup.json exist, copying over
2019-10-11 15:20:26> Program: Exe was not passed in. Not running contextual install
2019-10-11 15:20:26> RegistryService: RegKeyExists: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run has TeamsMachineInstaller. Data - C:\Program Files (x86)\Teams Installer\Teams.exe --checkInstall --source=PROPLUS
2019-10-11 15:20:26> RegistryService: TrySetRegKey: HKEY_CURRENT_USER\Software\Microsoft\Office\Teams\InstallSource created
2019-10-11 15:20:26> RegistryService: TrySetRegKey: HKEY_CURRENT_USER\Software\Microsoft\Office\Teams\InstallSource set successfully as MSI
2019-10-11 15:20:26> CheckForUpdateImpl: Couldn't write out staging user ID, this user probably shouldn't get beta anything: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry\packages\.betaId'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.StreamWriter.CreateFile(String path, Boolean append, Boolean checkHost)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize, Boolean checkHost)
at System.IO.File.InternalWriteAllText(String path, String contents, Encoding encoding, Boolean checkHost)
at System.IO.File.WriteAllText(String path, String contents, Encoding encoding)
at Squirrel.UpdateManager.CheckForUpdateImpl.getOrCreateStagedUserId()
2019-10-11 15:20:26> CheckForUpdateImpl: Failed to load local releases, starting from scratch: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry\packages\RELEASES'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Squirrel.Utility.LoadLocalReleases(String localReleaseFile)
at Squirrel.UpdateManager.CheckForUpdateImpl.<CheckForUpdate>d__2.MoveNext()
2019-10-11 15:20:26> CheckForUpdateImpl: Reading RELEASES file from C:\Users\bmtest\AppData\Local\SquirrelTemp
2019-10-11 15:20:26> CheckForUpdateImpl: First run or local directory is corrupt, starting from scratch
2019-10-11 15:20:26> ApplyReleasesImpl: No delta packages found. Applying current release package.
2019-10-11 15:20:26> ApplyReleasesImpl: getting squirrel aware apps failed with exception Could not find a part of the path 'C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry\current'.
2019-10-11 15:20:26> ApplyReleasesImpl: Writing files to app directory: C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry\current
2019-10-11 15:20:27> ApplyReleasesImpl: Squirrel Enabled Apps: [C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry\current\SkypeTelemetry.exe]
2019-10-11 15:20:43> ApplyReleasesImpl: Couldn't run Squirrel hook, continuing: C:\Users\bmtest\AppData\Local\Microsoft\SkypeTelemetry\current\SkypeTelemetry.exe: System.OperationCanceledException: The operation was canceled.
at System.Threading.CancellationToken.ThrowOperationCanceledException()
at Squirrel.Utility.<>c__DisplayClass11_0.<InvokeProcessAsync>b__0()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Squirrel.Utility.<InvokeProcessAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Squirrel.UpdateManager.ApplyReleasesImpl.<>c__DisplayClass16_1.<<invokePostInstall>b__2>d.MoveNext()
benly - That is EXACTLY what I am seeing too. We use MS Teams and also a 3rd party software that uses Squirrel and when they are both trying to update / install at the same time the same thing is happening here. The 3rd party software ends up in the Microsoft local folder and inside that application folder I see files referencing both the software and MS Teams. Did you end up figuring out anything that explains why this is happening and how to fix it?
benly - That is EXACTLY what I am seeing too. We use MS Teams and also a 3rd party software that uses Squirrel and when they are both trying to update / install at the same time the same thing is happening here. The 3rd party software ends up in the Microsoft local folder and inside that application folder I see files referencing both the software and MS Teams. Did you end up figuring out anything that explains why this is happening and how to fix it?
Any solution?
Unfortunately as far as I can tell, this is a flaw in how squirrel works. The machine wide installers will all run and sometimes they will just happen to install properly and other times they will conflict and install incorrectly. The only work around is a manual one. Delete the incorrect appdata folders in the users app data folder, then from the C:\program files<application machine wide installer folder> run the squirrel install file for each application, one at a time. These could be in c:\program files (x86)\ if it is a 32bit application on a 64 bit OS. I agree that this is a pain but it is the only way we are finding we can help our end users when the installer fails to install properly.
Getting this issue as well. It's hard to imagine why though. Unless Squirrel writes a folder path to a file shared between the processes, how could our installer get the modified path to %LocalAppData%\Microsoft??? Either a bug in Squirrel, or somehow Microsoft is temporarily override a system variable during the Teams install.
From what I’ve read online, squirrel does not queue application installs/updates. Or maybe I should say Windows doesn’t queue up squirrel updates. So multiple can attempt to run at the very same time. I think while both Teams and our other software that uses squirrel are installing, they overlap and Teams ends up in the appdata folder for the other software, and vice versa.
I REALLY don’t like how squirrel works.
Kyle
Kyle Horan Systems Administrator
Phone: 401.619.1714 Email: @.@.> Administrative Office 858 West Main Road Middletown, RI 02842 . [cid:PeoplesCU_Logo_Tag_7da1a58d-752c-4d5c-90ba-027f5028526e.jpg] https://www.peoplescu.com/ https://www.peoplescu.com/
[cid:036_sm_fb_a1347472-45be-4a0b-af83-b901fa688c57.png] https://www.facebook.com/peoplescu/ [cid:036_sm_in_468e365e-e301-4c97-a0b4-805cb9a8926e.png] https://www.linkedin.com/company/peoples-credit-union [cid:036_sm_twitter_ead36a19-13db-46c4-9186-b34bea9f203c.png] https://twitter.com/PeoplesCU [cid:036_sm_y2_45d41b4c-7f16-42de-b619-b5cde39239df.png] https://www.youtube.com/user/peoplescu [cid:036_sm_instagram_9927e091-e056-4b30-a2b6-e681664c9634.png] https://www.instagram.com/peoplescu/
NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C.2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. From: Ben Zuill-Smith @.> Sent: Wednesday, September 28, 2022 12:19 PM To: Squirrel/Squirrel.Windows @.> Cc: Kyle Horan @.>; Comment @.> Subject: Re: [Squirrel/Squirrel.Windows] Failure when 2 apps run Squirrel's auto-updater/installer (#1138)
The email below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
Getting this issue as well. It's hard to imagine why though. Unless Squirrel writes a folder path to a file shared between the processes, how could our installer get the modified path to %LocalAppData%\Microsoft??? Either a bug in Squirrel, or somehow Microsoft is temporarily override a system variable during the Teams install.
— Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Squirrel_Squirrel.Windows_issues_1138-23issuecomment-2D1261147054&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AO-H8oC6nah7pXKTwSbu06WpobcT3bzxBNujQxIKBCE&m=wLcvGBx5FvwnLiOxq-OAwkLiQ4XwVVDhON9kfg9W9v8&s=BlTwb7ZUXG9ppaQGatanZ5wQG6p0CjDd_e_a-6qaTYI&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ASJJZOZWDM4J3AHUO6XOL4LWARVXFANCNFSM4DYWNFTQ&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AO-H8oC6nah7pXKTwSbu06WpobcT3bzxBNujQxIKBCE&m=wLcvGBx5FvwnLiOxq-OAwkLiQ4XwVVDhON9kfg9W9v8&s=dcAcFTjGnSLytEKUOfBZw1hDgFdy_U8gbWEfi6mA1sk&e=. You are receiving this because you commented.Message ID: @.@.>>
This email has been scanned for spam and viruses by Proofpoint Essentials. Click herehttps://us1.proofpointessentials.com/index01.php?mod_id=11&mod_option=logitem&mail_id=1664381939-KFz41PHyTcTY&r_address=khoran%40peoplescu.com&report=1 to report this email as spam.
Right, but I'm trying to get at why. It's not simply that they aren't queued (though that could be a solution to resolve the issue). 2 processes are running the squirrel install at the same time. Generally, processes cannot modify another process' variables. Therefore Squirrel must be writing some install path to a file on the hardrive at some location common to both processes (this would be bad, they should write to unique locations). That then causes a race condition where each one is modifying that file and reading from that file and the wrong data is read by one or both processes and the install fails. So we should be able to find in this library where the code writes/reads to/from some common file.
I believe the problem may be in the extraction of the zipped program data from the deployment program.
2 or more programs may try to extract RELEASES,Updater.exe, and their nupkg to the same SquirrelTemp directory. See this line here. One program can overwrite the Updater and RELEASES file in the other program. This obviously will causes some strange results, especially if one program has a custom Updater.exe (likely Microsoft Teams does). It's hard to verify if this is the exact issue because I'm not experienced enough with C++ to know how to add logs and verify it. I imagine extracting files to a temporary, randomly named folder or a folder based on the deployment program's name would resolve this issue. Perhaps @anaisbetts or @robmen can verify this is the right approach. Wouldn't take much to implement I would think.