[GRASS-dev] [GRASS GIS] #2350: G7: r.texture large file support problem

[GRASS GIS]

#2350: G7: r.texture large file support problem
----------------------------+-----------------------------------------------
 Reporter:  neteler         |       Owner:  grass-dev@…              
     Type:  defect          |      Status:  new                      
 Priority:  normal          |   Milestone:  7.0.0                    
Component:  Raster          |     Version:  unspecified              
 Keywords:  LFS, r.texture  |    Platform:  Linux                    
      Cpu:  x86-64          |  
----------------------------+-----------------------------------------------

Comment(by glynn):

 Replying to [ticket:2350 neteler]:

 > There seems to be a large file support issue under certain (?)
 > circumstances:

 Why do you believe that this is related to LFS?

 >
 {{{
 WARNING: Unable to rename null file
          '/grassdata/patUTM32/alba_classification/.tmp/blade21/2161.1' to
 '/grassdata/patUTM32/alba_classification/cell_misc/x43140_2006_pca.1_ASM/null'
 WARNING: Unable to rename cell file
          '/grassdata/patUTM32/alba_classification/.tmp/blade21/2161.0' to
 '/grassdata/patUTM32/alba_classification/fcell/x43140_2006_pca.1_ASM'
 }}}

 These warnings are generated by Rast_close() or Rast_unopen(), and
 correspond to a rename() system call failing.

 Possible reasons for failure are listed in the rename(2) manual page, but
 the most likely reason is filesystem permissions. Ensure that you own all
 of the directories within the mapset, and that the owner has write
 permission on them.

 If you're using group-writeable mapsets (suppressing the mapset ownership
 check), be aware that a user having bit 0020 (group-write) set in their
 umask will cause this sort of issue (subdirectories created by commands
 run by that user won't be writeable by anyone else, resulting in maps
 which cannot be overwritten or removed). This is a large part of the
 reason why the mapset ownership check exists.

 Similar issues can arise from copying maps using standard (non-GRASS)
 tools (if run by a privileged user, they may copy the ownership).

 > Is r.texture supporting LFS?

 Modules typically don't need to do anything regarding LFS; the support is
 in the libraries. The main issue which affects modules is that they
 shouldn't assume that cell counts will fit into an "int" or even a "long".
 But even failing to do so won't have any effect upon I/O.

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