The build system captures the output of the 'R CMD check' command
and displays it. If you look at the devel build report you'll
see that it also displays the content of some of the files produced
by 'R CMD check':
? - openPrimeR.Rcheck/00install.out
? - openPrimeR.Rcheck/tests_i386/testthat.Rout
? - openPrimeR.Rcheck/tests_x64/testthat.Rout
? - openPrimeR.Rcheck/examples_i386/openPrimeR-Ex.timings
? - openPrimeR.Rcheck/examples_x64/openPrimeR-Ex.timings
Yes it will open these files in order to read their content but
openPrimeR-Ex_i386.Rout is not one them.
It also checks that those files exist before trying to open them.
If they don't exist, they're ignored. This is why the 'Tests output'
and 'Example timings' sections at the bottom of openPrimeR check
report in release are empty.
However I'm pretty confident that 'R CMD check' opens
openPrimeR-Ex_i386.Rout after running the examples in 32-bit
mode. I think it parses the file in order to detect/report
problems that happened during the run of the examples.
Just to clarify: I don't think the problem is that the file
doesn't exist when 'R CMD check' tries to open it. I think the
problem is that some process is still holding on the file (via
a write connection), which prevents 'R CMD check' from opening
it (even if it tries to open it in read-only mode).
Disabling parallel execution in your examples would be very
informative!
H.
On 03/22/2018 10:29 AM, Matthias D?ring wrote:
Dear Herv?,
thanks for the detailed explanation. I have, however, one question.
Isn't this rather a problem with the Bioconductor build system than
with the package itself? I will explain why I think so.
?From my limited understanding, it seems to me that the out file from
running the package examples, in this case, "openPrimeR-Ex.Rout" is
not read by R CMD check itself but only written to.
So, only after R CMD check has run, should the Bioconductor build
system try to open the file to do some checks (I don't know what it's
checking but apparently there is something of interest in the file).
At this point, there should be a check whether the file is available
for reading, shouldn't there be? I took a dive into the past and found
this comment from Martin Morgan to a person that had the same problem
as I, which suggests my view.
https://urldefense.proofpoint.com/v2/url?u=http-3A__grokbase.com_t_r_bioc-2Ddevel_11asgm4efj_development-2Dversion-2Dof-2Dbayseq-2Dfailing-2Dcheck-2Don-2Dwindows-2Dmachines&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=4dLit0LWO62L2Nbb1SDhPnTyk0HX5yPPi35QNl604X4&s=27EQuRiPmUYDaFi8VIl4UJ2WS43kJT6sHbKhljxra6M&e=
So I'm not sure if adjusting the parallel execution would be a
permanent fix that would ensure that all Bioconductor packages pass
the checks smoothly on Windows. Maybe Martin could comment on this as
well?
Kind regards
??Matthias
On 03/22/2018 05:08 PM, Herv? Pag?s wrote:
Hi Matthias,
Not sure what's causing this but I just wanted to mention a couple
of things:
Even though you didn't modify your package, it can start failing
for many reasons. The most common reason is that R or another package
that your package depends on was modified. It turns out that a few
days ago we updated R from 3.4.3 to 3.4.4 on the release build
machines. Not sure that's related to the error you're seeing on
tokay1 but this cannot completely be discarded.
Unlike Unix-like system, Windows doesn't let a process open a file
if the file is currently in use (by the same or another process).
The "cannot open file 'foo': Permission denied" error is typically
the result of such situation. This type of error can be hard to
reproduce because it won't necessarily happen each time one runs
'R CMD check' on Windows. It only happens if one process is still
holding on file 'foo' when another process tries to access 'foo'.
But sometimes the process holding on 'foo' finishes a little bit
earlier (and releases the file) or the process trying to access
'foo' does it a little bit later, and everything is fine.
Because of this, troubleshooting this kind of error (called a
race condition) can be tricky.
The first thing you could do is disable parallel execution in
your examples and see if that eliminates the issue. If you still
see the error, then you can remove doParallel/foreach from the
equation. If you don't see the error anymore (but you'll have
to wait several build iterations to be sure because you could
just be lucky that the race condition doesn't happen for a few
days in a row), then you can fairly suspect that the problem
has something to do with doParallel/foreach and contact the
doParallel/foreach folks.
Hope this helps,
H.
On 03/22/2018 07:31 AM, Matthias D?ring wrote:
Although I didn't make any changes to my package openPrimeR, it is
currently not passing the checks on tokay1 due to the following error
while running the examples:
* checking examples ...
** running examples for arch 'i386' ...Warning in file(con, "r") :
??? cannot open file '../openPrimeR-Ex_i386.Rout': Permission denied
Error in file(con, "r") : cannot open the connection
Execution halted
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_openPrimeR_tokay1-2Dchecksrc.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=HjFin7ZZwuYWdlO8wvE3KmoPwjRiq-bV_UKHWdKLLP4&m=SZhlV-e7h7S6Ndf9G2qUGp37kMZHgjDPmkvI7cCtGDA&s=eK8w8Wfg-rPx9HSrExZjtAqbHQSDmYOxNJvdltvzCTM&e=
I've just searched for this type of error and found that it can be
caused by the parallel backend if it isn't explicitly closed. However,
I'm not creating clusters manually but rather using the foreach package
for this purpose, so this shouldn't be the root of the problem.
Interestingly, there are no problems for the development version on
tokay2
(https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_openPrimeR_tokay2-2Dchecksrc.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=HjFin7ZZwuYWdlO8wvE3KmoPwjRiq-bV_UKHWdKLLP4&m=SZhlV-e7h7S6Ndf9G2qUGp37kMZHgjDPmkvI7cCtGDA&s=zAWDhUHJG5jAGFu2WUc1K_uSBXN1daXMN5VVObIUjEk&e=).
Should I just ignore this problem? Any pointers?
Best
? ?Matthias