r.info picks map from current Mapset instead of PERMANENT

[wenzeslaus]

In the following environment (GRASS Sample NC SPM Location):

> g.mapsets -p
Accessible mapsets:
user1 PERMANENT landsat
> g.list t=rast -m p=land*
landclass96@PERMANENT
landcover_1m@PERMANENT
landuse96_28m@PERMANENT

I can run r.univar:

> r.univar landclass96
...
n: 1554124
minimum: 1
maximum: 7
...

But r.info looks to a wrong Mapset:

> r.info landclass96
WARNING: G__open(read): Unable to open
         '/home/vasek/grassdata/nc_spm_08_grass7_tests/user1/cellhd/landclass96':
         No such file or directory
WARNING: G__open(read): Unable to open
         '/home/vasek/grassdata/nc_spm_08_grass7_tests/user1/cellhd/landclass96':
         No such file or directory
ERROR: Unable to open header file for raster map <landclass96@>

Moreover, there is a @ character in the Unable to open...map <landclass96@> message.

You can get the same errors by running the automated test suite:

cd /grass/source/code/root
./bin.../grass71 ~/grassdata/nc_spm_08/PERMANENT/ --exec python -m grass.gunittest.main --location nc_spm_08 --location-type nc

firefox testreport/index.html
firefox testreport/lib/python/gunittest/test_assertions/index.html

You can see the results of automated tests also online:

• ​http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
• ​http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-06-02-07-00/report_for_nc_spm_08_grass7_nc/testfiles.html
• ​http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-06-02-07-00/report_for_nc_spm_08_grass7_nc/raster/r.slope.aspect/test_r_slope_aspect/index.html

[glynn]

Replying to wenzeslaus:

But r.info looks to a wrong Mapset:

> r.info landclass96
WARNING: G__open(read): Unable to open
         '/home/vasek/grassdata/nc_spm_08_grass7_tests/user1/cellhd/landclass96':
         No such file or directory

This is caused by r65348, which constructs the path before the mapset has been resolved.

[annakrat]

Any progress on this? If not, I would suggest to revert it for now and test it properly before reintroducing it.

I will take a look ASAP. Martin

[martinl]

Try r65437

[wenzeslaus]

Replying to martinl:

Try r65437

Thanks, r65437 fixed the issue. Closing.

If somebody wants to test quickly, it can be tested for example with (r.info is used there):

# inside GRASS session in NC SPM
cd ./lib/python/gunittest/testsuite/
python test_module_assertions.py

Just for the record, the missing G_file_name(path, element, name, mapset); call originated in r65348.

[glynn]

Replying to martinl:

Try r65437

Does the write case need something similar?

More generally, why is "path" being constructed before the mapset has been determined?

Bear in mind that fully qualified names are valid for output files so long as the mapset is the current mapset.

[martinl]

Replying to glynn:

Does the write case need something similar?

More generally, why is "path" being constructed before the mapset has been determined?

right, it was not good idea, changed in r65453

[neteler]

Milestone renamed