Fabio, Judging from prior versions of your package, the function `tile_read` makes many assumptions as to what paths will look like, and also modifies paths. In this case, it appears to be thrown off by either the lower case drive name, or the forward slashes in the path. Presumably winbuilder is now running in a configuration that does different things with paths.
Under those new paths, your code will double up the path by pre-pending the current working directory. This is not a `system.file` issue. I just took the second part of (grabbed from the error message): 'd:/RCompile/CRANincoming/R-devel/uFTIR.Rcheck/d:/RCompile/CRANincoming/R-devel/lib/uFTIR/extdata/tile.bsp' and fed it to your function from the prior version of your package and was able to produce a doubled up path as above. Best, B. PS: with this type of thing it is always helpful if you can provide a link to an online repository with the version of the code that you are trying to submit. On Friday, September 3, 2021, 12:29:02 PM EDT, Fabio Corradini S. <fabio.corrad...@inia.cl> wrote: Dear All: I submitted a package to CRAN. I developed it in DEBIAN and tested it in R-HUB windows devel, windows release, and macOS. None of the systems throw an error to me, and I mainly get notes about the package archived condition. However, the package failed at win-builder devel, as in one of the tests I call base::system.file to read a file and the function --only there-- returns the file path twice. Does system.file work differently on windows? You can check out CRAN win-builder check.log at: < https://win-builder.r-project.org/incoming_pretest/uFTIR_0.1.3_20210903_174243/Windows/00check.log > Kind regards, Fabio -- [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel