New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nvda settings randomly resetting #3165
Comments
Comment 1 by jteh on 2013-04-17 19:52 |
Comment 2 by briang1 on 2013-04-18 07:49 The last time I saw this effect it turned out to be the computer or in fact a program running on it that seemed to interfere with some files being written to. However something like that should affect older versions of nvda equally as often as the newer ones I'd have thought. |
Comment 3 by camlorn on 2013-04-19 20:54 |
Comment 4 by briang1 on 2013-04-20 06:20 |
Comment 5 by camlorn on 2013-04-21 17:27 |
Comment 6 by jteh on 2013-04-23 05:01
|
Comment 7 by PZajda on 2013-09-13 17:55 I have done something which should fix this issue, I hop I understood the way to fix it correctly:
If the temporary config is not written correctly, the configuration shouldn't be change so not damaged too. It is available on git at: |
Comment 8 by jteh on 2013-09-13 21:06 I sincerely apologise for having wasted some of your time on this. |
I've seen this issue happen a few times recently on a fairly new laptop of a friend running Windows 10. It seems quite easy to implement this and I would be glad to do so. |
Please produce steps to reproduce the Sent from my heavily encrypted iPhone.
|
@derekriemer So far, I was unable to reproduce this reliably. It just sometimes happened after a shutdown/reboot of the computer. |
Are you sure that the computer is not trying to recover from an error, it bglists@blueyonder.co.uk
|
…refs issue nvaccess#3165) Instead of directly writing the file, a temporary file is created and moved to the final location. This prevents corrupt configuration files being written. Added a fileUtils module with just a FaultTolerantFile context manager for now to facilitate this pattern. Please update miscDependencies submodule to a revision that includes the osmove module.
…refs issue nvaccess#3165) Instead of directly writing the file, a temporary file is created and moved to the final location. This prevents corrupt configuration files being written. Added a fileUtils module with just a FaultTolerantFile context manager for now to facilitate this pattern. Please update miscDependencies submodule to a revision that includes the osmove module.
Making this a p1. While it doesn't cause a crash, the configuration getting corrupted and reset is very bad for the user when it happens and we've had quite a few reports of it now. @feerrenrut, would you mind taking care of this? @bramd kindly provided a PR (#5916) to fix this, but unfortunately, I didn't notice he had addressed my review comments and now we've broken it with recent config system changes. I think much of the PR is still usable though. See also #3165 (comment) for background. |
Thank you. This would be a greatly welcomed fix. See my request in #6969 as well.
|
…refs issue #3165) Instead of directly writing the file, a temporary file is created and moved to the final location. This prevents corrupt configuration files being written. Added a fileUtils module with just a FaultTolerantFile context manager for now to facilitate this pattern. Please update miscDependencies submodule to a revision that includes the osmove module.
Fixes issue #3165 Save configuration profiles and gesture maps as an atomic operation Instead of directly writing the file, a temporary file is created and moved to the final location. This prevents corrupt configuration files being written. Added a `fileUtils` module with just a `FaultTolerantFile` context manager for now to facilitate this pattern.
- Deprecated code removed: - PR #6878: `speech.REASON_*` constants, `controlTypes.REASON_*` should be used instead. (issue #6846) - PR #6877: `i18nName` for synth settings, `displayName` and `displayNameWithAccelerator` should be used instead. (issues #6846, #5185) - PR #6876: `config.validateConfig`. (issues #6846, #667) - PR #6875: `config.save`. (issue #6846) - PR #6914: Support Windows Calculator on Windows 10 Enterprise LTSB (Long-Term Servicing Branch) and Server. (issue #6914) - PR #6987: Reduced the chance of configuration file being corrupted when Windows shuts down. Configuration files are now written to a temporary file before replacing the actual configuration file. (issue #3165)
Reported by camlorn on 2013-04-17 13:24
This has happened twice in 3 days. Nvda will randomly forget all of my settings, including that nvda has been run on my computer before, re displaying the start up dialogs and resetting everything. Obviously, this is...problematic.
What do I need to do, besides (if I can) comment with how to reliably reproduce it?
The only changes in my setup since this has started happening are the enabling of the us-dvorak keyboard layout.
I'm on Version: master-9098,fb41602, and continually update as soon as new development snapshots come out. I first saw this on Monday the 15th.
The easiest fix would probably be making a backup of all settings at startup, of some sort. I'm not really sure why this is happening, but both times were while the system was being very sluggish--maybe some sort of interrupted file writing?
Blocked by #667
The text was updated successfully, but these errors were encountered: