Skip to content

Bug: Issues on Windows with SFN disabled

8 messages · Dirk Eddelbuettel, Tomas Kalibera, Kevin Ushey +2 more

Original
Tomas Kalibera
# 
An update on this. Writing R Extensions does not recommend to have a 
space character in R_HOME. This means that on Windows one either should 
have SFN enabled (which is still the common case), or install into a 
directory that does not have a space in its name (so specifically not 
into "Program Files"). This recommendation unfortunately needs to stay 
for now.

WRE recommends that Makefiles are written to be robust against space 
characters inside R_HOME. All path names passed from a Makefile to the 
shell should be quoted at least if they include R_HOME. Make "include" 
directives should not be used on path names that are derived from 
R_HOME, but one should instead use the "-f" option multiple times when 
recursively invoking make. Maintainers of packages that use "include" 
with R_HOME have been notified. Unfortunately, the number of packages 
that do not quote pathnames with R_HOME in Makefiles is rather large, so 
fixing will take some time.

Currently, R-devel should build fine on Windows with R_HOME including 
space, including all base and recommended packages, and tests for these 
packages should pass even though this is not regularly tested. If you 
find a case when this does not work, please submit a bug report.

Thanks
Tomas
On 10/20/2017 04:29 PM, Tomas Kalibera wrote:
Dirk Eddelbuettel
#
On 7 December 2017 at 17:56, Tomas Kalibera wrote:
| 
| An update on this. Writing R Extensions does not recommend to have a 
| space character in R_HOME. This means that on Windows one either should 
| have SFN enabled (which is still the common case), or install into a 
| directory that does not have a space in its name (so specifically not 
| into "Program Files"). This recommendation unfortunately needs to stay 
| for now.
| 
| WRE recommends that Makefiles are written to be robust against space 
| characters inside R_HOME. All path names passed from a Makefile to the 
| shell should be quoted at least if they include R_HOME. Make "include" 
| directives should not be used on path names that are derived from 
| R_HOME, but one should instead use the "-f" option multiple times when 
| recursively invoking make. Maintainers of packages that use "include" 
| with R_HOME have been notified. Unfortunately, the number of packages 
| that do not quote pathnames with R_HOME in Makefiles is rather large, so 
| fixing will take some time.
| 
| Currently, R-devel should build fine on Windows with R_HOME including 
| space, including all base and recommended packages, and tests for these 
| packages should pass even though this is not regularly tested. If you 
| find a case when this does not work, please submit a bug report.

Why does the Windows installer default to using a directory with spaces?

Related (but moderately more advanced), why does R still install "everything"
under one (versioned) directory so that uninformed users on upgrade "miss"
all previously installed packages?

Why not (with space for exposition here, imagine s/ // everywhere below)

    $SOMEROOTDIR / R /
                      R-a.b.c/          # before
                      R-a.b.d/          # d > c, here
                      site-library/     # with .libPaths having this preset?

I don't really care as I manage to work mostly / entirely on another OS, but
I just don't understand why we do not put two and two together. But I am
likely unaware of some salient issues.

In any event, I appreciate the thankless work of those taking care of Windoze
(ie Tomas, Jeroen, Duncan (now ex-officio), Brian, ...)

Dirk
Tomas Kalibera
#
On 12/07/2017 06:15 PM, Dirk Eddelbuettel wrote:
It's a convention on Windows and I guess there may be problems with 
permissions on other directories. My hope is we can make R work reliably 
without SFN just in time before SFN become disabled by default, after 
all, quoting pathnames in Makefiles (or shell scripts for that matter) 
is a good practice anyway and avoiding "include" is not a big problem as 
very few packages are affected.

But thanks for opening this and I am happy for insights from any Windows 
experts on the issue. I would not want to violate the convention for all 
users when just few of them have SFN disabled, and as I hope this will 
be fixed on R/packages side, but maybe the installer could at least 
detect the problem (when "Program Files" or another specified target 
directory did not have a short name). Or perhaps also suggest a 
different default. Certainly R could print a warning when it starts.

Tomas
Kevin Ushey
# 
For what it's worth, the Windows installers for other programming
language runtimes often install outside of Program Files, so at least
there is 'prior art' to motivate having R install directly into the
root of the home drive:

    - ActiveState Perl installs directly C:/Perl;
    - Python installs (when installing for all users) into C:/Python$VERSION;
    - The Ruby installers at https://rubyinstaller.org/ default to the
root home drive.

So I (as Dirk said earlier) would also be in favor of having R install
directly to the root of the home drive, with e.g. C:/R/R-x.y.z being
the default install location.

Best,
Kevin
On Fri, Dec 8, 2017 at 4:14 AM, Tomas Kalibera <tomas.kalibera at gmail.com> wrote:
Dirk Eddelbuettel
#
On 8 December 2017 at 08:52, Kevin Ushey wrote:
| For what it's worth, the Windows installers for other programming
| language runtimes often install outside of Program Files, so at least
| there is 'prior art' to motivate having R install directly into the
| root of the home drive:
| 
|     - ActiveState Perl installs directly C:/Perl;
|     - Python installs (when installing for all users) into C:/Python$VERSION;
|     - The Ruby installers at https://rubyinstaller.org/ default to the
| root home drive.
| 
| So I (as Dirk said earlier) would also be in favor of having R install
| directly to the root of the home drive, with e.g. C:/R/R-x.y.z being
| the default install location.

Yes! And also keep user-installed packages in C:/R/site-library/ by default.

Dirk


PS Thanks to an anonymous benefactor who corrected my inaccurate phrasing.
Zach Bjornson
# 
Thanks for fixing this!

For what it's worth, the Windows installers for other programming
language runtimes often install outside of Program Files, so at least
there is 'prior art' to motivate having R install directly into the
root of the home drive:


This is actually a pretty big peeve of mine. "Program Files" is where
programs are *supposed* to reside on Windows.
"everything"
"miss"
Will this work for native (C/C++) packages? I thought they need to have
matching ABIs with the R executable.

Zach
Zach Bjornson
# 
PS -- Microsoft's reasoning is explained in "Why do program files go into
the Program Files directory?"

https://blogs.msdn.microsoft.com/oldnewthing/20120307-00/?p=8153

There are a few useful comments below it as well, including some folks who
got bit by SFN. The mentioned logo/cert requirements are listed in

https://msdn.microsoft.com/en-us/library/windows/desktop/aa372825(v=vs.85).aspx

-Z
Paul McQuesten
# 
Does Windows allow creating a symlink to "C:/Program Files"?
If so, R could install into the conventional Windows location, but use the
symlink for all its access, yes?

Windows 10 command = mklink
On Fri, Dec 8, 2017 at 11:14 AM, Zach Bjornson <zbbjornson at gmail.com> wrote: