Cache for Desktop-UI transforms some folders to xx.gz files
Posted: Wed Nov 18, 2020 4:43 pm
Environment
Windows 2016 Server
WinCC-OA 3.16 p20
Windows 10 workstation
Recently we have discovered a problem with a windows-environment which runs an application which is viewed via a desktop-UI client. The desktop-UI is not able to switch from a Dark to a Light theme anymore. After some checks we discovered that the Cache folder at server-side had converted some 'folders' from the project to a .gz file. instead of keeping the folder as folder.
e.g. (environment with a problem)
<project>\colorDB\NightScheme (folder) -> <project>\cache\colorDB\NightScheme.gz (file)
e.g. (environment without a problem)
<project>\colorDB\NightScheme (folder) -> <project>\cache\colorDB\NightScheme (folder)
We tested the same application on a different environment which does work as supposed to be, so we suspect a setting somewhere in our IT environment to be wrong, but have no clue in which direction we need to search.
The IT environment is not controlled by us, also they maintainers have no clue what could be a cause, in their words "nothing is changed". So I would like to ask if someone has seen this behavior before, and maybe found a resolution for it?
Thanks, in advance.
Gr. Michel.
Windows 2016 Server
WinCC-OA 3.16 p20
Windows 10 workstation
Recently we have discovered a problem with a windows-environment which runs an application which is viewed via a desktop-UI client. The desktop-UI is not able to switch from a Dark to a Light theme anymore. After some checks we discovered that the Cache folder at server-side had converted some 'folders' from the project to a .gz file. instead of keeping the folder as folder.
e.g. (environment with a problem)
<project>\colorDB\NightScheme (folder) -> <project>\cache\colorDB\NightScheme.gz (file)
e.g. (environment without a problem)
<project>\colorDB\NightScheme (folder) -> <project>\cache\colorDB\NightScheme (folder)
We tested the same application on a different environment which does work as supposed to be, so we suspect a setting somewhere in our IT environment to be wrong, but have no clue in which direction we need to search.
The IT environment is not controlled by us, also they maintainers have no clue what could be a cause, in their words "nothing is changed". So I would like to ask if someone has seen this behavior before, and maybe found a resolution for it?
Thanks, in advance.
Gr. Michel.