[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 neteler):

 Replying to [comment:1 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?

 I got the idea from

 {{{
 Range of data:    min = -2147483648  max = -2147483648
 }}}

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

 Would it be possible to make the errno more visible or "clear"?

 > 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.

 Yes, I checked and the mapset owner has write permissions. So, the
 situation is this:

 {{{
 /grassdata/patUTM32/alba_classification
 - /grassdata/ is mounted to the actual blade (cluster system) via NFS
 - /grassdata/patUTM32/: I am owner of that, group write is set
 - /grassdata/patUTM32/alba_classification/: owned by the user having
 problems
 }}}

 This setting we use for years without troubles.

 > 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

 Here the various permissions:

 {{{
 [neteler at blade21 ~]$ ls -la /grassdata
 lrwxrwxrwx 1 root root 20 Mar  3  2012 /grassdata -> /storage/2/grassdata/

 [neteler at blade21 ~]$ ls -la /grassdata/ | grep patUTM
 drwxrwxr-x  97 neteler  gis       4096 Jun 23 16:23 patUTM32/

 [neteler at blade21 ~]$ ls -la /grassdata/patUTM32/ | grep alba
 drwxr-xr-x 14 lucadelu gis    4096 Jun 25 12:24 alba_classification/

 [neteler at blade21 ~]$ ls -la /grassdata/patUTM32/alba_classification/
 total 4260
 drwxr-xr-x 14 lucadelu gis    4096 Jun 25 12:24 ./
 drwxrwxr-x 97 neteler  gis    4096 Jun 23 16:23 ../
 -rw-------  1 lucadelu gis    1817 Jun 24 16:05 .bash_history
 -rw-r--r--  1 lucadelu gis     886 Jun 24 15:41 .bashrc
 drwx------  2 lucadelu gis    4096 Jun 25 17:17 cats/
 drwx------  2 lucadelu gis    4096 Jun 25 17:17 cell/
 drwx------  2 lucadelu gis    4096 Jun 25 17:17 cellhd/
 drwx------ 47 lucadelu gis    4096 Jun 25 17:17 cell_misc/
 drwx------  2 lucadelu gis    4096 Jun 25 17:11 colr/
 -rw-------  1 lucadelu gis      12 Jun 23 16:15 CURGROUP
 drwx------  2 lucadelu gis    4096 Jun 25 17:17 fcell/
 drwx------  2 lucadelu gis      10 Jun 23 16:15 g3dcell/
 drwx------ 10 lucadelu gis    4096 Jun 23 16:15 group/
 drwx------  2 lucadelu gis    4096 Jun 25 17:17 hist/
 -rw-------  1 lucadelu gis      70 Jun 24 09:57 legend
 -rw-r--r--  1 lucadelu gis 4264511 Jun 25 17:17 logfile
 -rw-r--r--  1 lucadelu gis    9916 Jun 24 17:18 logfile_size9
 -rw-r--r--  1 lucadelu gis    6810 Jun 25 15:14 method.py
 drwx------  2 lucadelu gis      30 Jun 25 15:56 sqlite/
 drwxr-xr-x  3 lucadelu gis      28 Jun 24 17:17 .tmp/
 -rw-------  1 lucadelu gis      81 Jun 23 16:15 VAR
 drwx------  9 lucadelu gis    4096 Jun 25 15:53 vector/
 -rw-------  1 lucadelu gis     355 Jun 25 17:11 WIND
 }}}

 > (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.

 Not sure yet if above cited permissions cause the error?

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