Problem saving .ps1 files after upgrade to 3.7.10

Product: PowerShell Universal
Version: 3.7.10

Hey PSU folks,

I upgraded to 3.7.10 today and started experiencing an issue when saving dashboard scripts I’m working on.

I’m using a multi-page dashboard and building out a new page. My usual process has a browser window to the page, while I work on the .ps1 file in VS Code. When I save my .ps1 file, I refresh the browser screen to see updated results. This has always worked just fine until now.

It seems something in PSU is locking the file when it’s open in a browser window. When I click save in VS Code I get an error failing to save the file due to EBUSY resource busy or locked.

I then refresh the page in the browser and try to save again. This time I get a different error saying the content of the file is newer. At this point I find the file is 0 bytes and the web page is blank. I cannot save the file unless I close the page in the browser, or I delete the file, and then clicking save works. To note, clicking Overwrite also works. A refresh of the web page reloads it at this point.

I’m not dead in the water working on my project, but this is impactful to my working process and can cause data loss. Any ideas?

2023-02-10_09-31-59

2023-02-10_09-38-15

2023-02-10_09-38-32

Update…Clicking Overwrite only works sometimes.

That looks like an OS level file lock to me.

Do you have the file open in another application in your OS?

A reboot of the OS should get rid of any hanging file locks.

I’ve checked open files and nothing listed. The only things running on this server is PSU and VS Code.
Tried rebooting and same problem.

To note I’ve been working on this page all week, and as of last night I was not having any troubles. This morning I performed the PSU upgrade and the problems started, with that being the only change.

If I open the file in Notepad++, I can make any changes and save as many times as I want without running into this problem. This is whether the web page is opened or not.

Looked into this maybe being an issue with VS Code and found the following …

VS Code will show you an error message when you try to save a file that cannot be saved because it has changed on disk. VS Code blocks saving the file to prevent overwriting changes that have been made outside of the editor.

I tried using ProcessExplorer but it only says Explorer.exe has the file open, and that’s b/c I have to open explorer to browse to the file.

Something seems to be changing the file on disk, and it’s an intermittent thing; somethings I can save without issue.

Seems to be something between VS Code and the new version of PSU. I tried upgrading to latest version of VS Code, but same issue. I also tried running VS Code with all plugins disabled, and same problem.

When I click save, the file is blanked out to 0 bytes and I get the error that it can’t save due to something doing something with the file. I actually lost it earlier and was able to dig up a backed up copy, but still lost work.

To note; when I stop the PowerShellUniversal service and edit the file I do not have any troubles. I can save as many times as I want using VS Code, so long as the PSU service is stopped.
Other ideas?

It could be an antivirus type program locking files periotically.

Hey everyone,

I ran this by a couple of server admins who claimed the AV would not do this, but the security team person I need to work with was out on TTO and when returned it took a while to get them involved. We were able to confirm our AV was not causing this issue.

I upgraded to PSU 3.7.11 and latest PoSh version, but still have the issue. I did further testing to find this only happens when I have a script in C:\ProgramData\UniversalAutomation\Repository\ and when the PowerShellUniversal service is running. I pulled the PSU logs to find this every time I encounter the issue …

2023-03-09 09:45:48.719 -06:00 [WRN] Failed to sync
System.IO.IOException: The process cannot access the file ‘C:\ProgramData\UniversalAutomation\Repository\dashboards\DashboardName\pages\ScriptName.ps1’ because it is being used by another process.
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.OSFileStreamStrategy…ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
at System.IO.File.OpenRead(String path)
at UniversalAutomation.Services.UniversalConfigurationService.SHA256CheckSum(String filePath) in C:\actions-runner_work\universal\universal\src\Universal.Server\Services\UniversalConfigurationService.cs:line 173
at UniversalAutomation.Services.UniversalConfigurationService.ShouldProcess(String fileName, String fullPath) in C:\actions-runner_work\universal\universal\src\Universal.Server\Services\UniversalConfigurationService.cs:line 152
at UniversalAutomation.Services.UniversalConfigurationService.NotifyChange(String fullPath) in C:\actions-runner_work\universal\universal\src\Universal.Server\Services\UniversalConfigurationService.cs:line 116

Afterwards I was researching PSU documentation for something else and came across this Best Practices - PowerShell Universal.

Avoiding Writing to the Repository Directory

The repository directory defaults to C:\ProgramData\UniversalAutomation\Repository

Writing files directly to the repository directory in your scripts can have adverse side effects on performance of the system. PowerShell Universal employs a file system watcher to check for changes to files made on disk. Any changes made within the directory trigger the watcher and configuration file reload verification.

In some instances, writing files can result in configuration reloads that may restart dashboards or cause internal caches to be cleared.

It’s recommended to avoid writing to this directory directly in a default configuration. If you would like to write to the directory, consider disabling the server-wide Auto Reload setting. This will disable the file system watcher and you will no longer risk impacting the configuration of the system.

I enabled the “Disable Auto Reload” setting and the problem went away. I’m concerned with what do I actually lose by disabling the auto reload? It’s rare that I edit or need to restart a dashboard, as I use multi-page dashboards and generally just work on the pages themselves, and they don’t require a dashboard restart. When I do edit a dashboard, I don’t mind restarting it.

I did start having an issue with a Do/Until loop and need to do some further testing to see if disabling auto reload is causing it or not. If the loop gets interrupted in some way refreshing the page, clicking back in the browser, and restarting the dashboard does not stop the loop. The only way I can stop it is to restart the PowerShellUniversal service itself.

Been using PSU for around 3 years now and have always used the default Repository directory, and just now started having this issue with the upgrade to 3.7.10 +. If I need to move the Repository directory, where can I find information on how to do this.

Thanks,
Rob

There is a file system watcher that is disabled when you change this setting. It watches the disk for changes and then invokes the configuration service to reload those changes.

The configuration service checks to see if the file has changed by running a SHA256 checksum across the contents. Based on the error you are seeing, it seems like the checksum is happening at the same time it’s attempting to do something else with the file that has an exclusive lock.

I think we need to open an issue for this because we made these changes to the configuration service recently and that is likely causing the issue. That said, I haven’t seen this myself so I might need some help getting it to break in my environment. I’ll open an issue in GitHub to track.

Thanks @adam!

Let me know if I can send you logs or anything to help with your investigation. Not sure if this helps, but:

  • I’m running on Server 2019.
  • I install PSU from MSI.
  • I use all default directories.
  • I upgraded from version 3.5.3 to 3.7.10, and that’s when I started encountering the problem.

Thanks again!
Rob