Turn off Windows shadow copy for my ini files?
Turn off Windows shadow copy for my ini files?
Hi,
my PB application is creating an ini file in %APPDATA%\appfolder\. Now I have two customers where all the changes my app is writing to the ini file are later on forgotten. Like it never was updated.
I found that Windows seem to create and handle some sort of shadow copy of the ini file. By this, all changes in the file are later ignored and the app forgot all changes. At one point, the settings where "fixated" and are not able to get changed any more.
Sadly, I found no way to fix this. Even if I let the customer delete the ini file (would create a new one), the application itself is presented the old ini file content. As if the file was still existing!
To all the Windows experts:
- How to turn off that feature for the affected file?
- How to avoid it from the beginning?
- Any idea what might have happened? I suspect that an Admin previously copied that file from some other system. But the user is having full permissions.
Restriction: In both cases, the end users does not have admin permissions and do not know the admin password.
Thanks,
Kukulkan
my PB application is creating an ini file in %APPDATA%\appfolder\. Now I have two customers where all the changes my app is writing to the ini file are later on forgotten. Like it never was updated.
I found that Windows seem to create and handle some sort of shadow copy of the ini file. By this, all changes in the file are later ignored and the app forgot all changes. At one point, the settings where "fixated" and are not able to get changed any more.
Sadly, I found no way to fix this. Even if I let the customer delete the ini file (would create a new one), the application itself is presented the old ini file content. As if the file was still existing!
To all the Windows experts:
- How to turn off that feature for the affected file?
- How to avoid it from the beginning?
- Any idea what might have happened? I suspect that an Admin previously copied that file from some other system. But the user is having full permissions.
Restriction: In both cases, the end users does not have admin permissions and do not know the admin password.
Thanks,
Kukulkan
Re: Turn off Windows shadow copy for my ini files?
This is probably UAC virtualization issue that kicks in when app tries to write to folder where current user does not have write permissions and instead of failing, it redirects that file to VirtualStore folder. There is a compiler option to disable this feature: "Request User mode for Windows Vista and above".
Re: Turn off Windows shadow copy for my ini files?
One other of the possible reasons would be forgetting ClosePreferences() after writing?
Or else, a location error:
%AppData% should be writable for the current user, but make no mistake:
GetUserDirectory(Type)
- #BP_Directory_ProgramData: program data directory of the current logged user.
- #PB_Directory_AllUserData: common program data directory (accessible to all users)
Or else, a location error:
%AppData% should be writable for the current user, but make no mistake:
GetUserDirectory(Type)
- #BP_Directory_ProgramData: program data directory of the current logged user.
- #PB_Directory_AllUserData: common program data directory (accessible to all users)
Re: Turn off Windows shadow copy for my ini files?
Thanks for the answers. My app works fine today on a few thousand Windows 7, 8.1 and 10 installations. Today I have only two such cases (known) where this strange issue kicks in.
I assume some wrong configuration or very much locked down system issues. Thus, I don't think I have to do something in my app. It also may have happened that some administrator manually copied another version of the ini file into this folder before my app was started the first time. Maybe this was the reason why Windows started to create shadow copies?
But the main question is how to turn off after it happened? Where in Windows can I fix the problem if it comes up? How to disable such behavior for the ini file?
My app created the subfolder in %APPDATA% and also all files inside including the .ini file. But only for this ini file Windows started to create such a shadow copy. So I definitely have had write permissions before.This is probably UAC virtualization issue that kicks in when app tries to write to folder where current user does not have write permissions and instead of failing, it redirects that file to VirtualStore folder.
I have exactly two functions (LoadSettings() and SaveSettings()) where ini-files are created, loaded and saved. I'm pretty sure there is no ClosePreferences() missingOne other of the possible reasons would be forgetting ClosePreferences() after writing?
I assume some wrong configuration or very much locked down system issues. Thus, I don't think I have to do something in my app. It also may have happened that some administrator manually copied another version of the ini file into this folder before my app was started the first time. Maybe this was the reason why Windows started to create shadow copies?
But the main question is how to turn off after it happened? Where in Windows can I fix the problem if it comes up? How to disable such behavior for the ini file?
Re: Turn off Windows shadow copy for my ini files?
This is the right way. Maybe after that happend, the user can start a "little helper.exe" with admin rights that delete this file...cas wrote:There is a compiler option to disable this feature: "Request User mode for Windows Vista and above".
or check the virtual store folder, what happend there...
Re: Turn off Windows shadow copy for my ini files?
Hi,
But I wonder why only a few percent of the users are affected (< 0,1%)? So I assumed that the software is fine...
I just googled a bit about Windows user mode and it seems that Windows runs all applications in user mode by default? Or is this some other "User mode"?
In the PB manual, Fred suggests to not activate this option if the app follows the Windows guidelines for files and registry. Using only %APPDATA% I believe I follow these guidelines, not writing to application folder or other locations. I fear that setting this option may cause problems for all the thousands other installations that work out of the box with current settings.
Again, I do not mainly look for a solution to prevent this for my App. It is only a very limited number of users affected. I look for the Windows options to fix it. How can my customer fix this in Windows if it happened?
Should I really create and deliver an exe file requiring Admin permissions and trying to delete the file then (like Bisonte mentions)? Is this the solution?
But I wonder why only a few percent of the users are affected (< 0,1%)? So I assumed that the software is fine...
I just googled a bit about Windows user mode and it seems that Windows runs all applications in user mode by default? Or is this some other "User mode"?
In the PB manual, Fred suggests to not activate this option if the app follows the Windows guidelines for files and registry. Using only %APPDATA% I believe I follow these guidelines, not writing to application folder or other locations. I fear that setting this option may cause problems for all the thousands other installations that work out of the box with current settings.
Again, I do not mainly look for a solution to prevent this for my App. It is only a very limited number of users affected. I look for the Windows options to fix it. How can my customer fix this in Windows if it happened?
Should I really create and deliver an exe file requiring Admin permissions and trying to delete the file then (like Bisonte mentions)? Is this the solution?
Re: Turn off Windows shadow copy for my ini files?
The path described in the manual is correct. Windows actually moves everything to where it
makes the most sense (for Windows). If a program does not have the necessary rights to write
to the registry or to a specific location, it is moved to the "Virtual Store".
This makes it possible to execute programs that were not created according to the "guidelines"
of the admin/user.
the user knowing exactly what is being changed. Also virus scanners sometimes provide such
strange settings.
You can ask the respective users which virus scanner is installed, or if they use "TuningTools".
However, some of these tools are also well hidden, such as Avira's system speedup... the user
doesn't really notice anything of it. And unfortunately this (if you use Avira as AV) is installed quickly...
The user mode in the compiler options only ensures that this virtualization is switched off.
My suggestion is not to have the whole program ask for admin rights. just provide a small utility
program that is started by the user separately (by a button click or menu option).
Translated with http://www.DeepL.com/Translator
makes the most sense (for Windows). If a program does not have the necessary rights to write
to the registry or to a specific location, it is moved to the "Virtual Store".
This makes it possible to execute programs that were not created according to the "guidelines"
of the admin/user.
Because many people believe the promises of various "tuning tools", a lot is put around withoutWhy does it affect so few users?
the user knowing exactly what is being changed. Also virus scanners sometimes provide such
strange settings.
You can ask the respective users which virus scanner is installed, or if they use "TuningTools".
However, some of these tools are also well hidden, such as Avira's system speedup... the user
doesn't really notice anything of it. And unfortunately this (if you use Avira as AV) is installed quickly...
The user mode in the compiler options only ensures that this virtualization is switched off.
My suggestion is not to have the whole program ask for admin rights. just provide a small utility
program that is started by the user separately (by a button click or menu option).
Translated with http://www.DeepL.com/Translator
Re: Turn off Windows shadow copy for my ini files?
Hi,
thanks you Bisonte for the detailed explanation. But delivering another executable seems overkill to me.
Isn't there a simple way of fixing this with Windows option? If someone with admin permissions simply deletes the file? Isn't that enough? If the user deletes it, for the app nothing has changed. It is still using some outdated other version from somewhere...
thanks you Bisonte for the detailed explanation. But delivering another executable seems overkill to me.
Isn't there a simple way of fixing this with Windows option? If someone with admin permissions simply deletes the file? Isn't that enough? If the user deletes it, for the app nothing has changed. It is still using some outdated other version from somewhere...
Re: Turn off Windows shadow copy for my ini files?
It is hard to help without code example. There can be many reasons why this fails. Tell your users that have this issue to send you logfile. Do something like this:
Also, enable compiler option "Request User mode for Windows Vista and above".
If this does not help then these users probably run your app under different user than currently logged in user (administrator or standard user). Anyway, logfile will help in finding a solution.
Code: Select all
Procedure LoadSettings()
;{ add these lines before OpenPreferences()
LogToFile("settings path="+settings$+" filesize="+FileSize(settings$))
f=OpenFile(#PB_Any,settings$)
If f=0
e=GetLastError_()
LogToFile("settings file error "+e)
Else
CloseFile(f)
LogToFile("settings read/write")
EndIf
;}
OpenPreferences()
...
EndProcedure
If this does not help then these users probably run your app under different user than currently logged in user (administrator or standard user). Anyway, logfile will help in finding a solution.
Re: Turn off Windows shadow copy for my ini files?
Thanks cas, but the creation and reading works with no errors. I do a lot of logging. OpenPreferences() and writing into it works like a charm. But if started again, the content is reset to some older state. Really strange.
But it only affects two users out of thousands. So I assume the software and my settings are fine.
If it happened, isn't there a simple way of fixing this with Windows option? If someone with admin permissions simply deletes the file? Isn't that enough?
But it only affects two users out of thousands. So I assume the software and my settings are fine.
If it happened, isn't there a simple way of fixing this with Windows option? If someone with admin permissions simply deletes the file? Isn't that enough?
Re: Turn off Windows shadow copy for my ini files?
I would say you need to collect much more information about that issue.
Neither access right nor shadow copies should have anything to do with that.
Simply try to open the ini with write rights and you know if there is a permission
or temporary access problem caused by an AV Software.
Maybe right after closing preferences, open them again and check it there correct written.
Neither access right nor shadow copies should have anything to do with that.
Simply try to open the ini with write rights and you know if there is a permission
or temporary access problem caused by an AV Software.
Maybe right after closing preferences, open them again and check it there correct written.
Re: Turn off Windows shadow copy for my ini files?
There is no need to collect any more information except these which i suggested to you (file path, file size and if file can be opened for writing). Actually, only file path would be probably enough. You can then tell user to delete preferences file manually inside that path that will be in logfile and then re-start your app.
How do you know that writing into it works like a charm? ClosePreferenecs() does not have return value to tell you if preferences were ACTUALLY written to disk. If you pass read-only preferences file to OpenPreferences(), preferences will be read from it, but when you modify preferences and call ClosePreferences(), data will not be written to disk. Sounds like that is probably what is happening here.
We are not psychic, without some logs there is no way to know for sure what is happening and how to fix it.
Collect these logs and then you will know what is actually happening.
How do you know that writing into it works like a charm? ClosePreferenecs() does not have return value to tell you if preferences were ACTUALLY written to disk. If you pass read-only preferences file to OpenPreferences(), preferences will be read from it, but when you modify preferences and call ClosePreferences(), data will not be written to disk. Sounds like that is probably what is happening here.
We are not psychic, without some logs there is no way to know for sure what is happening and how to fix it.
Collect these logs and then you will know what is actually happening.