Re: path.expand fails on some windows platform

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

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

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

Hello Manuel,

This isn't new behavior, and I'd argue it is a bug on two counts, not just=
 one.
First, the error message itself is wrong. "Name too long?" has nothing to =
do with path length. That string comes from R's internal filename encoding=
 conversion routine on Windows, and it fires whenever the conversion betwe=
en the native encoding and wide characters fails for any reason. A usernam=
e with "=C3=A1" in it isn't too long, it's failing translation. At minimum=
 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 no=
n-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 still =
going through a lossy conversion, most likely where R falls back to the Wi=
ndows shell folder APIs to locate Documents when R_USER is unset. That's c=
onsistent with what you're seeing: define R_USER and the problem vanishes,=
 because R takes the environment string as-is instead of deriving the path=
 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 con=
taining non-ASCII characters), where the recommended workaround was the sa=
me one you found: set R_USER before launching R. Tomas Kalibera responded =
at the time that he couldn't find an obvious place where the Windows code =
gets the conversion wrong and couldn't reproduce it without OneDrive invol=
ved, so the reproduction details matter here. A couple of diagnostics wort=
h adding to your report to make it actionable for R-core: The Mail Archive

Output of sessionInfo() and Sys.getlocale() on an affected machine
Whether OneDrive is redirecting the Documents folder on the affected accou=
nts (localized folder names like "Documentos" plus OneDrive path injection=
 is the common thread in prior reports)
Output of utils::readRegistry("Software\Microsoft\Windows\CurrentVersion\E=
xplorer\User Shell Folders", "HCU") so they can see the raw path R is tryi=
ng to convert

The same conversion failure also surfaces downstream in anything that call=
s file.exists(), so this isn't cosmetic. Since you've confirmed it across =
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 f=
ault is in base R, not Rcmdr. GitHub
The .Renviron workaround is fine as a stopgap, but users with accented use=
rnames shouldn't need to know it exists.

In your particular case, =C3=B1 is non-ASCII (it sits outside the 7-bit AS=
CII 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 <m=
[email protected]> wrote:

> Dear all.
> =


> When using R version 4.6.1 on certain Windows platforms where the userna=
me 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 v=
ariable. 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.expan=
d(), such as file.exists().
> =


> This behavior has been confirmed on multiple computers by various users =
running Windows 10 and 11.
> =


> In my opinion, this is a bug, as a standard path expansion should not tr=
igger 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-guide=
.html
> and provide commented, minimal, self-contained, reproducible code.
> =


-----------------------3288e89445e9bd7077e78f3bb962aff3--

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

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

wsC5BAEBCgBtBYJqToXkCRBLpiqh7hNGwEUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jnkjfjc5WNOWCAiymVQPmfRSPNNkmiv/mlcyC2
tqfjVeAWIQQD5syCXHAFH0sgxKtLpiqh7hNGwAAA4mYH/RVasuiBH9vSSvWE
N9Fq6cnTmcqhNraOv8E3aSmLa553jhkxveryE3zFjXQEhVae7qJvDIu07sTj
cgSxGyVBi1xko9Le+h6Zn7oGoffZmCLOl2rZxi+CBDXDpgEs64Y88oOMKBuK
Pbyv9DGVlNg97OQ3jGsmaWm/rm0rzmKjQ6BTrwIEJV9TxroGUp5KMRaJSB4i
JxS3IdBwVEM+0/Tg1i2/LFVdqyCUEYWLRw+Bs6cpZxR2BPkWthI6EjF0dWL8
rfxc+a5Ce+BjmjcSaWnaFTpUwV3WSjAVXbk7Vo/YsmyICOsPQujAoUVWF4cK
w/m4hhLdDc7bsQTOU6WhPFdrbBY=
=IMfs
-----END PGP SIGNATURE-----


--------3aa80d262fed7ca368d17ca549b4c256f737a8f537781fe1d35835743fd78aa8--


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