Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Use currently saved settings on logon screen fails with non-ASCII username #3092

nvaccessAuto opened this Issue Mar 19, 2013 · 6 comments


None yet
1 participant

Reported by LJWatson on 2013-03-19 10:51
Using a Microsoft Surface Pro. In Preferences > General settings, when selecting "Use currently saved settings on the logon and other secure screens" button, the UAC opens and when "Yes" is selected, the following error is returned:

"Error copying NVDA user settings".

Comment 1 by jteh on 2013-03-19 22:25
Please reproduce the problem and then provide a log file as explained in ReportingIssues#ProvidingLogFiles. You'll need to set the log level to input/output.

Attachment NVDA_log-file_2013-03-26 added by LJWatson on 2013-03-26 16:56
NVDA log file

Comment 2 by LJWatson on 2013-04-01 12:20
Uploaded the log file. I didn't receive an email update to the ticket though, so adding in this comment just in case.

Comment 3 by jteh on 2013-04-02 02:29
I'm guessing you have non-ASCII characters in your username (i.e. the é in Léonie)?

Technical: When we elevate to set the system config, slave gets the arguments from sys.argv, but sys.argv is ANSI in Python 2.x. Arrrg! We need this in Unicode. I guess we can decode using mbcs, as the username is hopefully in the system code page. Alternatively, we could retrieve the command line arguments using Windows Unicode functions, though I'm not sure where we'd put this code.

Thoughts, Mick?
Changed title from "Use currently saved settings on logon screen returns error" to "Use currently saved settings on logon screen fails with non-ASCII username"
Milestone changed from None to 2013.2

Comment 4 by mdcurran on 2013-04-02 02:52
in tryCopyFile, I believe we should decode sourcePath and destPath from mbcs to unicode if they are indeed ansi. This is of course before we try to prepend the back slashes. Interestingly tryRemoveFile does not have the issue as we seem to use MovefileA specifically if its not unicode. For tryCopyFile though I think its shorter to correctly decode rather than trying to use both A/W functions all the way down.

Comment 5 by mdcurran on 2013-04-03 02:48
Fixed this specific situation in a290a16. In the end the changes were made in nvda_slave and config._setSystemconfig rather than touching install.tryCopyFile.
Milestone changed from 2013.2 to 2013.1
State: closed

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015

@nvaccessAuto nvaccessAuto added this to the 2013.1 milestone Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment