Describe the bug
A clear and concise description of what the bug is.
SSL-enabled session failed to start. Barrier is unable to open the right created trustedServers.txt. I am wondering that's because the path contains wide characters, since my username is in wide characters.

To Reproduce

Steps to reproduce the behavior:

1. Run barrier by a user with name contains wide character
2. Set as client and enable SSL
3. Connect a SSL-enabled server
4. After trusted the peer, the service does not actually running. Error log is found.

Expected behavior
Works with username contains wide character

Screenshots
If applicable, add screenshots to help explain your problem.

Please do not link to image hosting sites, as these can be ephemeral. Instead, attach them to the issue.

Error log:

[2020-12-07T11:57:10] INFO: service command updated
[2020-12-07T11:57:11] NOTE: connecting to '10.10.xxx.xxx': 10.10.xxx.xx:24800
[2020-12-07T11:57:11] INFO: OpenSSL 1.0.2l  25 May 2017
[2020-12-07T11:57:11] NOTE: server fingerprint: DD:90:85:3F:50:B9:84:04:80:8E:46:92:A6:71:9D:5F:83:3D:18:32
[2020-12-07T11:57:11] NOTE: trustedServersFilename: C:\Users\小明\AppData\Local\Barrier/SSL/Fingerprints/TrustedServers.txt
[2020-12-07T11:57:11] NOTE: Unable to open trustedServersFile: C:\Users\小明\AppData\Local\Barrier/SSL/Fingerprints/TrustedServers.txt
[2020-12-07T11:57:11] ERROR: failed 

Desktop (please complete the following information):

• OS: Windows 10
• Barrier version 2.3.3

Additional context

Server is barrier 2.3.3 running on Fedora 32. Connection can be established if SSL-disabled on both sides.