[R-pkg-devel] R CMD check getting stalled

[Henrik Bengtsson]

[re-sending using from email address for this list]

On Thu, May 28, 2015 at 7:53 PM, Hadley Wickham <h.wickham at gmail.com> wrote:
> Ok, it looks like it's actually quite a subtle problem. (Thanks to
> Winston Chang for tracking it down). The root of the problem appears
> to be the call to du at
> https://github.com/wch/r-source/blob/9ffe87264a1cd59a31a829f72d57af0f1bfa327a/src/library/tools/R/check.R#L3639
>
> With 32-bit R Sys.which("du") finds Rtools/bin/du.exe, whereas 64-bit
> R finds c:/windows/system32/du.exe (see attached screenshot).

Huh, screenshots? ;)

So, I can reproduce this on Windows 7 64-bit, IFF, I do:

> file.copy("C:/Rtools/bin/du.exe", "C:/Windows/system32/du.exe")

$ echo %PATH%
C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;C:\Windows;C:\Windows\system32

$ i386\Rscript.exe --vanilla -e "Sys.which('du')"
                             du
"C:\\Windows\\system32\\du.exe"
$ Rscript.exe --vanilla -e "shell('du')"
27797   ./i386
28413   ./x64
56275   .

$ x64\Rscript.exe --vanilla -e "Sys.which('du')"
                       du
"C:\\Rtools\\bin\\du.exe"
$ Rscript.exe --vanilla -e "shell('du')"
27797   ./i386
28413   ./x64
56275   .

However, without that C:/Windows/system32/du.exe (seems like a
mistake), both R builds finds the one in "C:\\Rtools\\bin\\du.exe".


BTW, this seems to be another example of what was reported in R-devel
thread '[Rd] How best to get around shadowing of executables by
system()'s prepending of directories to Windows' PATH?' on 2015-05-18
(https://stat.ethz.ch/pipermail/r-devel/2015-May/071195.html).


Details on the Rtools that I have:

$ ls -l C:/Rtools/bin/du.exe
-rwxr-xr-x 1 hb mkpasswd 177191 Oct 13  2014 C:/Rtools/bin/du.exe
$ md5sum C:/Rtools/bin/du.exe
408d9043dd90cf90fbde66f8bef2fcbe *C:/Rtools/bin/du.exe
$ cat C:/Rtools/VERSION.txt
Rtools version 3.3.0.1958


/Henrik

On Thu, May 28, 2015 at 7:53 PM, Hadley Wickham <h.wickham at gmail.com> wrote:
> Ok, it looks like it's actually quite a subtle problem. (Thanks to
> Winston Chang for tracking it down). The root of the problem appears
> to be the call to du at
> https://github.com/wch/r-source/blob/9ffe87264a1cd59a31a829f72d57af0f1bfa327a/src/library/tools/R/check.R#L3639
>
> With 32-bit R Sys.which("du") finds Rtools/bin/du.exe, whereas 64-bit
> R finds c:/windows/system32/du.exe (see attached screenshot).
>
> Hadley
>
>
> On Thu, May 28, 2015 at 4:04 PM, Uwe Ligges
> <ligges at statistik.tu-dortmund.de> wrote:
>> I guess a package that was installed by root and later on checked by a
>> regular user or some such, so that permissions do not match.
>>
>> I think I'd try to remove the package from all libraries and try again. And
>> note that network drives/mounts may be the source of such a problem when
>> some listings are disabled.
>>
>> Best,
>> Uwe Ligges
>>
>>
>>
>>
>> On 28.05.2015 23:02, Hadley Wickham wrote:
>>>>
>>>> Wild guess: It's not the package but the file system or file permissions
>>>> so
>>>> that you cannot determine the size.
>>>
>>>
>>> Do you have any thoughts on where specifically to look? Permissions of
>>> the library or of the current dir?
>>>
>>> I also wondered if it might be caused by a recursive link that caused
>>> the size inspection to never finish, but there aren't any symlinks in
>>> the package.
>>>
>>> I have one student in a class of ~60 students who has this problem.
>>> The package source is at https://github.com/hadley/rv2/tree/check-me,
>>> but it seems unlikely to be related to the package as it works for
>>> everyone else.
>>>
>>> Hadley
>>>
>>
>
>
>
> --
> http://had.co.nz/
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>