detritus check NOTE

[joelnitta]

I am using {future.apply} in one of my packages (https://github.com/ropensci/canaper/), and encounter this NOTE when running checks on rhub (Windows Server 2022, R-devel, 64 bit) and CRAN:

* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
  'Rscript1058267d0c10' 'Rscriptbd4267d0c10' 'lastMiKTeXException'

My guess is this is being caused by the same thing documented in the thread "R for Windows leaves detritus in the temp directory".

Do you know if that was ever corrected or have a solution to it?

Thanks!

[HenrikBengtsson]

This is most likely because there are some left-over background workers still running at the end of R CMD check. This only happens on MS Windows, where clusters can survive the main R session that launched them. You need to test on R-devel (>= 4.3.0) to reproduce this locally.

If you use plan(multisession) is your vignettes or package tests(*), make sure to stop the parallel workers at the end by calling plan(sequential). I've now documented this is https://future.futureverse.org/articles/future-7-for-package-developers.html#making-sure-to-stop-parallel-workers (as well as in https://parallelly.futureverse.org/reference/makeClusterPSOCK.html)

(*) This can currently happen in vignettes or package tests, but it looks like it won't happen due to example code, at least not when I've checked via GitHub Actions (https://github.com/HenrikBengtsson/teeny/tree/R_CMD_check/detritus_files).

[joelnitta]

Thanks! I found a stray plan(multisession) without a corresponding plan(sequential) to close it out in one of my vignettes, so I think that was causing the problem.

BTW gnuwin32/system.c now includes a comment "Unix does unlink(ifile) here, but Windows cannot delete open files":

/* in case getpid() is not unique -- has been seen under Windows */
	    snprintf(ifile, 1024, "%s/Rscript%x%x", tm, getpid(), 
		     (unsigned int) GetTickCount());
	    ifp = fopen(ifile, "w+b");
	    if(!ifp) R_Suicide(_("creation of tmpfile failed -- set TMPDIR suitably?"));
	    /* Unix does unlink(ifile) here, but Windows cannot delete open files */

I suppose this means the NOTE will not go away on Windows if workers are not shut down properly?

[HenrikBengtsson]

suppose this means the NOTE will not go away on Windows if workers are not shut down properly?

Yes, I'm pretty sure R itself won't close those internally-created temporary files. I now also believe that is a fortunate misfeature, because how they reveal how we might have background R processes still running.

[joelnitta]

I thought at first it was something related to simply using future.apply but now I realize I had some stray workers. Good to know!