Re: path.expand fails on some windows platform

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8124503994635045936==
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3362982b88c6bccae2a1c0d9ba32b48e193ec0f5b4a12ecb5ab64e1c09e6688f"; charset=utf-8

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------3362982b88c6bccae2a1c0d9ba32b48e193ec0f5b4a12ecb5ab64e1c09e6688f
Content-Type: multipart/mixed;boundary=---------------------3d325574c275dd89ed3370fbecf31ef2

-----------------------3d325574c275dd89ed3370fbecf31ef2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

A quick follow-up on my earlier remark about dropping the =C3=B1, I half s=
aid it in jest... and since that along will not solve the problem - it des=
erves a serious explanation of why that's harder than it sounds.

Renaming a Windows account does not rename the profile folder. The account=
 name and the profile path are two separate things that only look coupled.=
 When an account is first created, Windows generates the profile directory=
 under C:\Users using the username at that moment, records that path in th=
e registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Profile=
List<SID>\ProfileImagePath, and never touches it again. Rename the account=
 from "Mu=C3=B1oz" to "Munoz" through the control panel, netplwiz, or Acti=
ve Directory, and you'll log in as Munoz while everything still lives in C=
:\Users\Mu=C3=B1oz. The =C3=B1 that R is choking on is still right there i=
n the path.

So there are really only three ways to actually get the non-ASCII characte=
r out of the profile path:

Create a brand new local or domain account with an ASCII-only name, log in=
to it once so Windows builds a clean profile folder, then migrate the old =
profile's data over manually. Tedious but safe.
Edit ProfileImagePath in the registry to point at a renamed folder. This i=
s the "registry surgery" option, and it breaks anything that stored an abs=
olute path to the old location: application configs, scheduled tasks, OneD=
rive sync roots, certificate stores in some cases, and countless hardcoded=
 references in AppData. I would not do this on a machine I cared about.

Reimage and start over with an ASCII username.

None of these is proportionate to the actual problem. Setting R_USER in .R=
environ is one line, survives R upgrades, and touches nothing else on the =
system. That's the right mitigation until this is fixed in base R where it=
 belongs.
The broader point stands: a user named Pe=C3=B1a should not have to choose=
 between their name and a working path.expand(). The bug is in the encodin=
g conversion, not in the username.

again, =


Best regards,
Gregg



On Wednesday, July 8th, 2026 at 10:16 AM, Gregg Powell <g.a.powell@protonm=
ail.com> wrote:

> Hello Manuel,
> =


> This isn't new behavior, and I'd argue it is a bug on two counts, not ju=
st one.
> First, the error message itself is wrong. "Name too long?" has nothing t=
o do with path length. That string comes from R's internal filename encodi=
ng conversion routine on Windows, and it fires whenever the conversion bet=
ween the native encoding and wide characters fails for any reason. A usern=
ame with "=C3=A1" in it isn't too long, it's failing translation. At minim=
um the error text should say what actually happened.
> Second, the underlying conversion failure shouldn't be happening at all =
on a modern build. Since R 4.2 the Windows builds are UCRT-based with UTF-=
8 as the native encoding, which was supposed to put exactly this class of =
non-ASCII path problem to bed. If path.expand("~") still chokes on "=C3=A1=
" in R 4.6.1, then some code path in the home directory derivation is stil=
l going through a lossy conversion, most likely where R falls back to the =
Windows shell folder APIs to locate Documents when R_USER is unset. That's=
 consistent with what you're seeing: define R_USER and the problem vanishe=
s, because R takes the environment string as-is instead of deriving the pa=
th itself. GitHub
> This has been reported to R-core before in nearly identical form. There'=
s a 2024 r-help thread with the same error, same root cause (a home path c=
ontaining non-ASCII characters), where the recommended workaround was the =
same one you found: set R_USER before launching R. Tomas Kalibera responde=
d at the time that he couldn't find an obvious place where the Windows cod=
e gets the conversion wrong and couldn't reproduce it without OneDrive inv=
olved, so the reproduction details matter here. A couple of diagnostics wo=
rth adding to your report to make it actionable for R-core: The Mail Archi=
ve
> =


> Output of sessionInfo() and Sys.getlocale() on an affected machine
> Whether OneDrive is redirecting the Documents folder on the affected acc=
ounts (localized folder names like "Documentos" plus OneDrive path injecti=
on is the common thread in prior reports)
> Output of utils::readRegistry("Software\Microsoft\Windows\CurrentVersion=
\Explorer\User Shell Folders", "HCU") so they can see the raw path R is tr=
ying to convert
> =


> The same conversion failure also surfaces downstream in anything that ca=
lls file.exists(), so this isn't cosmetic. Since you've confirmed it acros=
s multiple machines on Win10 and Win11, this belongs on R's Bugzilla (bugs=
.r-project.org) rather than just a package repo issue tracker, because the=
 fault is in base R, not Rcmdr. GitHub
> The .Renviron workaround is fine as a stopgap, but users with accented u=
sernames shouldn't need to know it exists.
> =


> In your particular case, =C3=B1 is non-ASCII (it sits outside the 7-bit =
ASCII range, at U+00F1). Maybe your life would be simpler if you drop the =
~.
> =


> best regards,
> Gregg Powell
> =


> =


> =


> On Wednesday, July 8th, 2026 at 8:53 AM, Manuel Mu=C3=B1oz M=C3=A1rquez =
<[email protected]> wrote:
> =


> > Dear all.
> >
> > When using R version 4.6.1 on certain Windows platforms where the user=
name contains non-ASCII characters (such as "=C3=A1"), the command:
> > path.expand("~")
> > fails with the following error:
> > Error: file name conversion problem -- name too long?
> >
> > This occurs when the Windows OS does not define the R_USER environment=
 variable. In these cases, a call to Sys.getenv("R_USER") returns an
> > empty string ("").
> >
> > However, if an .Renviron file is created with a valid path, such as:
> > R_USER=3D"C:\Users\%Username%\Documents"
> > then path.expand() works properly no matter if which the %Username% is=
.
> >
> > This error propagates to other functions that internally call path.exp=
and(), such as file.exists().
> >
> > This behavior has been confirmed on multiple computers by various user=
s running Windows 10 and 11.
> >
> > In my opinion, this is a bug, as a standard path expansion should not =
trigger a conversion error under these circumstances. Or is this the
> > expected behavior in this scenario?
> >
> > More info:
> >
> > https://github.com/RCmdr-Project/rcmdr/issues/8
> >
> > Thank in advance.
> >
> > --
> > Manuel Mu=C3=B1oz M=C3=A1rquez <[email protected]>
> >
> > ______________________________________________
> > [email protected] mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide https://www.R-project.org/posting-gui=
de.html
> > and provide commented, minimal, self-contained, reproducible code.
> >
-----------------------3d325574c275dd89ed3370fbecf31ef2--

--------3362982b88c6bccae2a1c0d9ba32b48e193ec0f5b4a12ecb5ab64e1c09e6688f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJqToc9CRBLpiqh7hNGwEUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnmVR+pdMCzU3AqWUi+lCzCR1HnPVnu7JdDDQF
aiH/9kEWIQQD5syCXHAFH0sgxKtLpiqh7hNGwAAA2/IIALj62eJWS3KS37g5
mdL8hGtx4UWDlteGR10M5xpcUktNFrNqTbvyM8Fin/7O+1rMtidHsR43msYb
DhgnJpIQFaeF4HMciWvZehvqbkQYysu6nQSLVv7NBF4nUK+Q649ls8vo9DUv
jY0l3385vW+fArwD2EHjjQNFyzQYV3l74vi67pgH3pajaeaziJps1IDgN60E
eIpa0GbC8F3NsvbUrH1IzG5BCbu/PCUtp571TVs39BNGOlOgwcGbFaq1ohxe
SN/8q9qjeP3mWnnrivdLJ6xIFJkJSYcn4+SsogadbGIlfwgH87+DLOWFinIv
YGHlr+mWlFj9zNMkZHlRTDqqjkA=
=XZke
-----END PGP SIGNATURE-----


--------3362982b88c6bccae2a1c0d9ba32b48e193ec0f5b4a12ecb5ab64e1c09e6688f--


--===============8124503994635045936==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline