[GRASS-dev] Re: [GRASS GIS] #1276: r.null in winGRASS does not work properly

[GRASS GIS]

#1276: r.null in winGRASS does not work properly
------------------------------+---------------------------------------------
 Reporter:  helena            |       Owner:  grass-dev@…              
     Type:  defect            |      Status:  new                      
 Priority:  critical          |   Milestone:  6.4.2                    
Component:  Raster            |     Version:  6.4.1 RCs                
 Keywords:  r.null, wingrass  |    Platform:  MSWindows 7              
      Cpu:  Unspecified       |  
------------------------------+---------------------------------------------

Comment(by hamish):

 Replying to [comment:9 glynn]:
 > > Also, I notice that close_new() (in lib/gis/closecell.c) doesn't
 examine
 > > the return codes from either close() or remove(); it may be worth
 > > checking those.

 Replying to [comment:10 hamish]:
 > done in r50404 in devbr6.

 hmmm, now r.to.vect (and r.circle, and probably many others) reports a
 bunch of problems, even on linux:

 {{{
 WARNING: Unable to delete prior null-cells file
 WARNING: Unable to delete the temporary null-cells file
 WARNING: Unable to delete prior 'fcell' file
 WARNING: Unable to delete the f_format file
 WARNING: Unable to delete the prior 'cell' file
 WARNING: Unable to delete the temporary 'cell' file
 WARNING: Unable to delete the f_quant file
 }}}

 but no such warnings appear when running r.null on the latest nightly
 build of 6.5svn on Windows XP. (& problem persists)

 > AFAICT, the only way for G_close_cell() to not delete that file
 > and not print a warning is if `G__open_null_write()` fails at line
 > 207.

 aside:
 {{{
             null_fd = G__open_null_write(fd);
             if (null_fd <= 0)
                 return -1;
             if (null_fd < 1)
                 return -1;
 }}}

 (`G__open_null_write()` returns -1 on failure otherwise a new fd for the
 null file)

 more needless duplication. I'm getting the idea that there may be more
 sloppy code in this file..

 > bug: close(fd) is called twice, (??)

 fixed in devbr6.

 > Otherwise, it should attempt to rename the file, and any failure
 > should generate a warning. There aren't any return statements in
 > close_new() between renaming the null file and renaming the
 > cell/fcell file, so I don't know how this situation can arise.

 maybe this part of the code isn't being entered:
 {{{
 if (ok && (fcb->temp_name != NULL)) {
 }}}

 ?  I've added some more debug messages, we'll see what they have to say.


 Hamish

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