This has me stumped. I know this came up on the list about 2 years ago, but
that was of little help.
I tried running:
s.surf.rst input=1999 elev=chl_a field=4 maskmap=water
and several variations such as -t, dmin=10 and such. I keep getting the
error
"File size limit exceeded"
Afterward there is then a new file in the .tmp diectory of 2 gig. I have no
quotas. Running ulimit shows unlimited. I am running Linux with ext3.
I even tried using 'dd if=/dev/zero of=testfile bs=1024 count=3145728' from
within the GRASS> prompt, and produced a 3 gigb file in the same .tmp
directory! I also produced a 17 gig file!
Why if s.surf.rst stopping at 2 gig when other programs don't?
Thank you for any insight you can provide.
Jim
Jim Browne wrote:
This has me stumped. I know this came up on the list about 2 years ago, but
that was of little help.
I tried running:
s.surf.rst input=1999 elev=chl_a field=4 maskmap=water
and several variations such as -t, dmin=10 and such. I keep getting the
error
"File size limit exceeded"
Afterward there is then a new file in the .tmp diectory of 2 gig. I have no
quotas. Running ulimit shows unlimited. I am running Linux with ext3.
I even tried using 'dd if=/dev/zero of=testfile bs=1024 count=3145728' from
within the GRASS> prompt, and produced a 3 gigb file in the same .tmp
directory! I also produced a 17 gig file!
Why if s.surf.rst stopping at 2 gig when other programs don't?
GRASS doesn't attempt to use "large file support" (i.e. supporting
files whose sizes wouldn't fit into a "long"). This feature is risky,
so we don't use it (unlike certain OS vendors who just enable it by
default and wait for the bug reports to turn up).
If you want to handle files larger than 2Gb, you need a 64-bit
platform.
Alternatively, you could try enabling large file support yourself with
e.g.
CFLAGS='-g -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' ./configure ...
although I offer no guarantee that this will actually work (i.e. it
may well cause crashes even when dealing with files smaller than 2Gb).
--
Glynn Clements <glynn.clements@virgin.net>