initGRASS file.access test shows inconsistent behaviour

[gisma]

Using Windows 10 running something like:

rgrass7::initGRASS(gisBase = "C:\\OSGeo4W64\\apps\\grass\\grass-7.7.svn", home = tempdir(), gisDbase = tempdir(), mapset = "PERMANENT", location = "tmp", override = TRUE )

I am getting the warning:

Warning message: In rgrass7::initGRASS(gisBase = "C:\\OSGeo4W64\\apps\\grass\\grass-7.7.svn", : working directory not writable, using tempfile for GISRC

Tracing this down it seems to be the file access test in line 107 of the initGRASS function `:

(file.access(".", 2) == 0) returns TRUE while the implemented isTRUE(file.access(".", 2) == 0) returns FALSE

Actually file acces is granted but in the latter case the warning is thrown and a temporary .rcgrass7 file is generated. Actually this is not a problem at all but the warning is kind of confusing and the check seems to be inconsistent. No warning at all running it under Linux. I am not sure if I am missing something but any suggestions are welcome.

thanks Chris

Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252   
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C                   
[5] LC_TIME=German_Germany.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] rgrass7_0.1-12 XML_3.98-1.16  sp_1.3-1       link2GI_0.3-5 

loaded via a namespace (and not attached):
 [1] zoo_1.8-4          remotes_2.0.2      sf_0.7-1           lattice_0.20-35   
 [5] usethis_1.4.0      yaml_2.2.0         spacetime_1.2-2    base64enc_0.1-3   
 [9] rlang_0.2.2        pkgbuild_1.0.2     e1071_1.7-0        R.oo_1.22.0       
[13] DBI_1.0.0          RSAGA_1.2.0        foreign_0.8-69     glue_1.3.0        
[17] withr_2.1.2        R.utils_2.7.0      sessioninfo_1.1.0  foreach_1.4.4     
[21] plyr_1.8.4         stringr_1.3.1      commonmark_1.5     raster_2.7-15     
[25] R.methodsS3_1.7.1  devtools_2.0.1     codetools_0.2-15   memoise_1.1.0     
[29] callr_3.0.0        ps_1.1.0           class_7.3-14       gdalUtils_2.0.1.14
[33] xts_0.11-1         Rcpp_0.12.18       classInt_0.2-3     backports_1.1.2   
[37] desc_1.2.0         pkgload_1.0.2      debugme_1.1.0      FNN_1.1.2.1       
[41] fs_1.2.6           digest_0.6.17      stringi_1.2.4      processx_3.2.0    
[45] grid_3.4.3         rprojroot_1.3-2    rgdal_1.3-6        cli_1.0.0         
[49] tools_3.4.3        magrittr_1.5       gstat_1.1-6        crayon_1.3.4      
[53] xml2_1.2.0         shapefiles_0.7     prettyunits_1.0.2  spData_0.2.9.4    
[57] assertthat_0.2.0   roxygen2_6.1.0     rstudioapi_0.7     iterators_1.0.10  
[61] R6_2.2.2           units_0.6-0        intervals_0.15.1   compiler_3.4.3   ```

[rsbivand]

Thanks, this is not the rgrass7 repo, rather a development repo for using sf classes for vector data. Please see this thread in grass-stats list: https://lists.osgeo.org/pipermail/grass-stats/2018-September/001768.html; the warning was inserted to handle the OSGeo4W console which puts the user in a no-write-access folder for no good reason. Now OSGeo4W has lost iconv.dll, so there is no easy solution. I'll look at this issue, but putting the throwaway RC file in the R tempdir shouldn't be a problem, but I agree that the warning may be confusing.

[gisma]

Thanks for clarifying and sorry for using the wrong repo :-( I think it is ok to close the issue?

[rsbivand]

The actual repo is on R-Forge, but stars has not moved as fast as sf, so my idea of refreshing rgrass7 is waiting for now. The R-Forge SVN repo may move to github sometime. I'll close when I find out how to suppress the spurious warning, and report here when done.

[gisma]

Great. Thanks!

[rsbivand]

On Windows 10, running in an OSGeo4W console, R 3.5.1, rgrass7 0.1-12, isTRUE(file.access(".", 2) == 0) returns TRUE when the directory is writeable, FALSE when it is not writeable. This is also the case when running in a basic Windows command prompt. So I cannot replicate the issue. You have a lot of extra packages loaded, could you please try just at the Windows command prompt, starting R for example as "C:/Program Files/R/R-3.5.1/bin/x84/R.exe".

[gisma]

Thanks, I will check this ASAP (means when getting hold of Windows). It could be that calling R from the OSGeo4W console makes the difference. I avoid to do so, I am using instead the link2GI::linkGRASS7 function for defining the necessary environment settings. Finally I call initGRASS. Probably I have to drill down here.

[rsbivand]

OK, so this is probably actually a link2GI issue. I never use OSGeo4W either, but some people do, and it starts by default in a directory without write access. Most Windows command prompt windows, or RGui/RStudio, will start in directores with write permissions.