[GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

[GRASS GIS]

#2031: G_legal_filename() cleanup patch for GRASS 6
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  grass-dev@…              
      Type:  defect   |      Status:  closed                   
  Priority:  normal   |   Milestone:  6.4.4                    
 Component:  LibGIS   |     Version:  svn-releasebranch64      
Resolution:  fixed    |    Keywords:                           
  Platform:  All      |         Cpu:  All                      
----------------------+-----------------------------------------------------

Comment(by hamish):

 Hi,

 r60000,1 need to be reverted. There are tons of refactoring changes in
 trunk which do not belong in G6. This is not a bug fix, just removal of
 many safety checks.

 This is a blocker for 6.4.4 AFAIAC.

 MarkusN:
 > IMHO rather than having this test in hundreds of modules it should
 > be done in the respective library function.

 Sure, start by doing it in the library too, and in the parser, as multiple
 layers of safety. I don't object to that at all, but for G6 it is simple:
 do not risk changing stuff which does not need to be changed. The law of
 unintended consequences is just too strong. Refactoring goes in trunk not
 the stable branch.

 It was already established in #2025, commants 7 & 8 that this should not
 be backported.

 The bug in question (AIUI) was limiting output non-map ''data'' (text,
 image, ..) files written out to the filesystem by artificial
 legal_filename tests on them, so if you wanted output="summary.txt" to be
 output="C:\Users\me\summary.txt" you were blocked.
 What r60000 seems to do is remove the legal_filename checks for grass
 raster/vector map ''map'' names which should keep the checks. And I'd
 argue that as long as the library checks are missing in G6's parser and
 scattered library functions (as in many cases they seem to be), it is
 better to have the module fail at startup with the sometimes-gratuitous
 checks rather than waiting to see it fail at the end when it tries to
 write out the result map, probably leaving (possibly large) .tmp/ files
 behind too.


 And again, even if this were a valid candidate for G6, backporting stuff
 directly to 6.4 without going into devbr6 for at least light/any testing
 first, especially anything which touches core libgis, especially a time
 right before RC release, is incredibly risky for anything which is not a
 critical bug fix, and not an environment I can justify contributing my
 time to.


 sorry if I'm grumpy, but I'm at the end of my rope about this.

 regards,
 Hamish

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