[GRASS-dev] Re: [GRASS GIS] #1507: r.in.gdal & others: -e must only modify the current mapset's WIND file

[GRASS GIS]

#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
---------------------------------------------+------------------------------
 Reporter:  hamish                           |       Owner:  grass-dev@…              
     Type:  defect                           |      Status:  new                      
 Priority:  blocker                          |   Milestone:  6.4.2                    
Component:  Default                          |     Version:  svn-trunk                
 Keywords:  r.in.gdal, r.external, v.in.ogr  |    Platform:  All                      
      Cpu:  All                              |  
---------------------------------------------+------------------------------

Comment(by hamish):

 Replying to [comment:2 neteler]:
 > I am not at all convinced that this change in known behaviour
 > should reach GRASS 6.4.

 my take on it--

 backwards compatibility is allowed to be broken in cases where the
 previous behaviour was clearly in error and harming the user. in this case
 we have the competing interests of conserving expected behaviour (warts
 and all) versus the fact that the previous behaviour was is serious
 violation of the rule where modules are only allowed to make modifications
 within the current mapset. to allow that risks mayhem in a
 classroom/research team multi-user environment with a shared PERMANENT
 [can't trust file system write permissions to save us].

 (modifying newly created locations/mapsets outside of the current one is
 of course ok -- but only during the process of creating them)


 the decision of which of those two interests is more important is based on
 how bad the design bug was and how core or peripheral the feature change
 will be. there's no correct answer, just a judgment call. either way we
 win somehow, either way we lose somehow.


 In this case I would not be too surprised if someone had a processing
 script expecting the old behaviour, which is quite unfortunate, but for my
 2c I think the gross violation of g.access rules is the worse of the two
 options.

 certainly if we decide to backport this to 6.4 it should feature
 prominently in the release notes.


 > AFAIK the functionality is there on purpose...

 what was it? I mean versus having the module change the current WIND file
 only? If it is for r.in.gdal & v.in.ogr & newly created locations it's
 already taken care of, because G_make_location() takes &cellhd as one of
 its function argument and so the new DEFAULT_WIND and WIND are already set
 to match the import map's bounds.


 best,
 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1507#comment:3>
GRASS GIS <http://grass.osgeo.org>