A quick follow-up on my earlier remark about dropping the ñ, I half said it in jest... and since that along will not solve the problem - it deserves 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 the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList<SID>\ProfileImagePath, and never touches it again. Rename the account from "Muñoz" to "Munoz" through the control panel, netplwiz, or Active Directory, and you'll log in as Munoz while everything still lives in C:\Users\Muñoz. The ñ that R is choking on is still right there in the path. So there are really only three ways to actually get the non-ASCII character out of the profile path: Create a brand new local or domain account with an ASCII-only name, log into 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 is the "registry surgery" option, and it breaks anything that stored an absolute path to the old location: application configs, scheduled tasks, OneDrive 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 .Renviron 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ña should not have to choose between their name and a working path.expand(). The bug is in the encoding conversion, not in the username. again, Best regards, Gregg On Wednesday, July 8th, 2026 at 10:16 AM, Gregg Powell <[email protected]> wrote: > 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 between > the native encoding and wide characters fails for any reason. A username with > "á" 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 non-ASCII > path problem to bed. If path.expand("~") still chokes on "á" 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 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 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 > containing non-ASCII characters), where the recommended workaround was the > same 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 > involved, so the reproduction details matter here. A couple of diagnostics > worth 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 accounts > (localized folder names like "Documentos" plus OneDrive path injection 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 trying to convert > > The same conversion failure also surfaces downstream in anything that calls > 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 fault is in base R, not Rcmdr. GitHub > The .Renviron workaround is fine as a stopgap, but users with accented > usernames shouldn't need to know it exists. > > In your particular case, ñ 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ñoz Márquez > <[email protected]> wrote: > > > Dear all. > > > > When using R version 4.6.1 on certain Windows platforms where the username > > contains non-ASCII characters (such as "á"), 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="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.expand(), 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 > > 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ñoz Márquez <[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. > >
signature.asc
Description: OpenPGP digital signature
______________________________________________ [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.
