Tue, Jun 21 2005
19:29:57
|
|
Request created by guest
|
|
Subject: r.proj works ONLY when source and target mapset names are identical
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: cvs 21.06.2005
r.proj cannot handle a following situation
1. source
name: 452_211_scinawa
location: caves_65
mapset: PERMANENT
2. target
name: 452_211_scinawa_utm
location: caves_utm33
mapset: topo
GRASS 6.1.cvs (caves_utm33):~ > r.proj input=452_211_scinawa location=caves_65
mapset=PERMANENT output=452_211_scinawa_utm
mkdir: cannot create directory `/home/grassdata/caves_65/topo/.tmp': No such
file or directory
ERROR: can't make mapset element .tmp/quercus.biol.uni.wroc.pl
(/home/grassdata/caves_65/topo/.tmp)
It is trying to create a .tmp in a non-existant mapset! Like if it couldn't read
that the source mapset is PERMANENT. Somehow the source and target mapset names
get mixed.
Maciek |
|
Wed, Jun 22 2005
15:40:20
|
|
Mail sent by glynn@gclements.plus.com
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17081.27200.114831.982586@gargle.gargle.HOWL>
|
Date |
Wed, 22 Jun 2005 14:40:16 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
In-Reply-To |
<20050621172957.57FE110016A@lists.intevation.de>
|
References |
<20050621172957.57FE110016A@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3362
> Subject: r.proj works ONLY when source and target mapset names are identical
> mkdir: cannot create directory `/home/grassdata/caves_65/topo/.tmp': No such
file or directory
>
> ERROR: can't make mapset element .tmp/quercus.biol.uni.wroc.pl
> (/home/grassdata/caves_65/topo/.tmp)
>
> It is trying to create a .tmp in a non-existant mapset! Like if it
> couldn't read that the source mapset is PERMANENT. Somehow the
> source and target mapset names get mixed.
This is a very good reason not to use G_tempfile() for normal
temporary files.
There is no guarantee that the user can create files or directories
within the source location.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Thu, Jun 23 2005
00:51:26
|
|
Mail sent by paul-grass@stjohnspoint.co.uk
|
|
Return-Path |
<paul-grass@stjohnspoint.co.uk>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 22 Jun 2005 23:54:07 +0100 (BST)
|
From |
Paul Kelly <paul-grass@stjohnspoint.co.uk>
|
To |
Morten Hulden <morten@untamo.net>
|
Cc |
grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
In-Reply-To |
<42B9E013.9020804@untamo.net>
|
Message-ID |
<Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk>
|
References |
<20050621172957.57FE110016A@lists.intevation.de> <17081.27200.114831.982586@gargle.gargle.HOWL> <42B9E013.9020804@untamo.net>
|
MIME-Version |
1.0
|
Content-Type |
TEXT/PLAIN; charset=US-ASCII; format=flowed
|
X-SA-Do-Not-Run |
Yes
|
X-SA-Exim-Connect-IP |
217.10.143.90
|
X-SA-Exim-Mail-From |
paul-grass@stjohnspoint.co.uk
|
X-SA-Exim-Scanned |
No (on customer-relay-1.mail.uksolutions.net); SAEximRunCond expanded to false
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On Thu, 23 Jun 2005, Morten Hulden wrote:
> Glynn Clements wrote:
>
>>
>> This is a very good reason not to use G_tempfile() for normal
>> temporary files.
>>
>> There is no guarantee that the user can create files or directories
>> within the source location.
>>
>
> So, not a r.proj specific problem then. A lot of modules may suffer from
> using G_tempfile().
>
> r.proj is not calling G_tempfile() directly. In the case mentioned above
> suspects are datum.c, get_datum_name.c, get_ell_name.c or some other function
> from /lib/gis files.
Even so, it should be creating a temp file in the current mapset, not in
the location that is being projected from. Perhaps the location switching
code in r.proj might not be handling the mapset correctly.
Although I tried to reproduce the problem and couldn't.
> What is the correct fix? To rewrite G_tempfile()?
See
http://grass.itc.it/pipermail/grass5/2005-January/016997.html
I suspect Brad's recent changes to make G_asprintf() use G_tempfile()
should be reverted?
Paul
|
|
Thu, Jun 23 2005
01:32:36
|
|
Mail sent by morten@untamo.net
|
|
Return-Path |
<morten@untamo.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<42B9F50B.4000709@untamo.net>
|
Date |
Thu, 23 Jun 2005 01:32:27 +0200
|
From |
Morten Hulden <morten@untamo.net>
|
User-Agent |
Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Paul Kelly <paul-grass@stjohnspoint.co.uk>
|
Cc |
grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
References |
<20050621172957.57FE110016A@lists.intevation.de> <17081.27200.114831.982586@gargle.gargle.HOWL> <42B9E013.9020804@untamo.net> <Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk>
|
In-Reply-To |
<Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk>
|
Content-Type |
text/plain; charset=ISO-8859-1; format=flowed
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Paul Kelly wrote:
> On Thu, 23 Jun 2005, Morten Hulden wrote:
>
>> Glynn Clements wrote:
>>> This is a very good reason not to use G_tempfile() for normal
>>> temporary files.
>>>
>>> There is no guarantee that the user can create files or directories
>>> within the source location.
>>>
>>
>> So, not a r.proj specific problem then. A lot of modules may suffer
>> from using G_tempfile().
>>
>> r.proj is not calling G_tempfile() directly. In the case mentioned
>> above suspects are datum.c, get_datum_name.c, get_ell_name.c or some
>> other function from /lib/gis files.
>
>
> Even so, it should be creating a temp file in the current mapset, not in
> the location that is being projected from. Perhaps the location switching
> code in r.proj might not be handling the mapset correctly. Although I
> tried to reproduce the problem and couldn't.
I could not reproduce the problem either; I was able to reproject from a
mapset where I did not have write permission, but r.proj did not even
try to create a .tmp directory anywhere in the source mapset.
OTOH I am running a CVS version a few weeks old. I'll update and see
what happens. Although r.proj has not changed some underlying library
routines may have ...
rgds
Morten
|
|
Thu, Jun 23 2005
02:42:43
|
|
Mail sent by morten@untamo.net
|
|
Return-Path |
<morten@untamo.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<42BA0580.7080105@untamo.net>
|
Date |
Thu, 23 Jun 2005 02:42:40 +0200
|
From |
Morten Hulden <morten@untamo.net>
|
User-Agent |
Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
Cc |
grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
References |
<20050621172957.57FE110016A@lists.intevation.de> <17081.27200.114831.982586@gargle.gargle.HOWL> <42B9E013.9020804@untamo.net> <Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk> <42B9F50B.4000709@untamo.net>
|
In-Reply-To |
<42B9F50B.4000709@untamo.net>
|
Content-Type |
text/plain; charset=ISO-8859-1; format=flowed
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Morten Hulden wrote:
> Paul Kelly wrote:
>>> r.proj is not calling G_tempfile() directly. In the case mentioned
>>> above suspects are datum.c, get_datum_name.c, get_ell_name.c or some
>>> other function from /lib/gis files.
>> Even so, it should be creating a temp file in the current mapset, not
>> in the location that is being projected from. Perhaps the location
>> switching
>> code in r.proj might not be handling the mapset correctly. Although I
>> tried to reproduce the problem and couldn't.
> I could not reproduce the problem either; I was able to reproject from a
> mapset where I did not have write permission, but r.proj did not even
> try to create a .tmp directory anywhere in the source mapset.
>
> OTOH I am running a CVS version a few weeks old. I'll update and see
> what happens. Although r.proj has not changed some underlying library
> routines may have ...
With CVS 20050623 I get the same error:
mkdir: cannot create directory
`/var/local/grass/data/global_ll/morten/.tmp': No such file or directory
ERROR: can't make mapset element .tmp/xxxx.yyyyyy.zzz
(/var/local/grass/data/global_ll/morten/.tmp)
So the bug was introduced in some library routines since 20050606 (last
time I updated from CVS), but not in r.proj itself.
|
|
Thu, Jun 23 2005
03:09:24
|
|
Mail sent by morten@untamo.net
|
|
Return-Path |
<morten@untamo.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<42BA0BC1.2050000@untamo.net>
|
Date |
Thu, 23 Jun 2005 03:09:21 +0200
|
From |
Morten Hulden <morten@untamo.net>
|
User-Agent |
Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
Cc |
grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
References |
<20050621172957.57FE110016A@lists.intevation.de> <17081.27200.114831.982586@gargle.gargle.HOWL> <42B9E013.9020804@untamo.net> <Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk> <42B9F50B.4000709@untamo.net> <42BA0580.7080105@untamo.net>
|
In-Reply-To |
<42BA0580.7080105@untamo.net>
|
Content-Type |
text/plain; charset=ISO-8859-1; format=flowed
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Morten Hulden wrote:
> Morten Hulden wrote:
>
>> Paul Kelly wrote:
>>
>>>> r.proj is not calling G_tempfile() directly. In the case mentioned
>>>> above suspects are datum.c, get_datum_name.c, get_ell_name.c or some
>>>> other function from /lib/gis files.
>>>
>>> Even so, it should be creating a temp file in the current mapset, not
>>> in the location that is being projected from. Perhaps the location
>>> switching
>>> code in r.proj might not be handling the mapset correctly. Although I
>>> tried to reproduce the problem and couldn't.
>>
>> I could not reproduce the problem either; I was able to reproject from
>> a mapset where I did not have write permission, but r.proj did not
>> even try to create a .tmp directory anywhere in the source mapset.
>>
>> OTOH I am running a CVS version a few weeks old. I'll update and see
>> what happens. Although r.proj has not changed some underlying library
>> routines may have ...
>
>
> With CVS 20050623 I get the same error:
>
> mkdir: cannot create directory
> `/var/local/grass/data/global_ll/morten/.tmp': No such file or directory
> ERROR: can't make mapset element .tmp/xxxx.yyyyyy.zzz
> (/var/local/grass/data/global_ll/morten/.tmp)
>
> So the bug was introduced in some library routines since 20050606 (last
> time I updated from CVS), but not in r.proj itself.
>
>> Paul Kelly wrote:
>> See
>> http://grass.itc.it/pipermail/grass5/2005-January/016997.html
>>
>> I suspect Brad's recent changes to make G_asprintf() use G_tempfile()
>> should be reverted?
Yes, it's in G_asprintf(). Simply changing G_tempfile() back to
tmpfile() on line 37 in asprintf.c fixes it. There may be other
consequences so I suggest the maintainer makes the reversion himself in cvs.
rgds
Morten
|
|
Thu, Jun 23 2005
12:37:15
|
|
Mail sent by paul-grass@stjohnspoint.co.uk
|
|
Return-Path |
<paul-grass@stjohnspoint.co.uk>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 23 Jun 2005 11:40:06 +0100 (BST)
|
From |
Paul Kelly <paul-grass@stjohnspoint.co.uk>
|
To |
Brad Douglas <rez@touchofmadness.com>
|
Cc |
Morten Hulden <morten@untamo.net>, grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
In-Reply-To |
<1119491852.26679.549.camel@albedo>
|
Message-ID |
<Pine.LNX.4.60.0506231127540.28447@agrippa.ukshells.co.uk>
|
References |
<20050621172957.57FE110016A@lists.intevation.de> <17081.27200.114831.982586@gargle.gargle.HOWL> <42B9E013.9020804@untamo.net> <Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk> <42B9F50B.4000709@untamo.net> <42BA0580.7080105@untamo.net> <42BA0BC1.2050000@untamo.net> <1119491852.26679.549.camel@albedo>
|
MIME-Version |
1.0
|
Content-Type |
TEXT/PLAIN; charset=US-ASCII; format=flowed
|
X-SA-Do-Not-Run |
Yes
|
X-SA-Exim-Connect-IP |
217.10.143.90
|
X-SA-Exim-Mail-From |
paul-grass@stjohnspoint.co.uk
|
X-SA-Exim-Scanned |
No (on customer-relay-1.mail.uksolutions.net); SAEximRunCond expanded to false
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On Wed, 22 Jun 2005, Brad Douglas wrote:
> On Thu, 2005-06-23 at 03:09 +0200, Morten Hulden wrote:
>>>> I suspect Brad's recent changes to make G_asprintf() use G_tempfile()
>>>> should be reverted?
>>
>> Yes, it's in G_asprintf(). Simply changing G_tempfile() back to
>> tmpfile() on line 37 in asprintf.c fixes it. There may be other
>> consequences so I suggest the maintainer makes the reversion himself in cvs.
>
> This was my doing. I was unaware of the implications of G_tempfile().
> Can someone back out the changes?
I have changed G_asprintf() back to use tmpfile() instead of G_tempfile()
and fopen() and it seems to have fixed the r.proj bug.
Probably would need to think about systematically changing some other
occurences of G_tempfile() as Glynn and Morten suggested.
Paul
|
|
Thu, Jun 23 2005
19:01:12
|
|
Mail sent by glynn@gclements.plus.com
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17082.60113.496145.159834@gargle.gargle.HOWL>
|
Date |
Thu, 23 Jun 2005 18:01:05 +0100
|
To |
Paul Kelly <paul-grass@stjohnspoint.co.uk>
|
Cc |
Brad Douglas <rez@touchofmadness.com>, Morten Hulden <morten@untamo.net>, grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical
|
In-Reply-To |
<Pine.LNX.4.60.0506231127540.28447@agrippa.ukshells.co.uk>
|
References |
<20050621172957.57FE110016A@lists.intevation.de> <17081.27200.114831.982586@gargle.gargle.HOWL> <42B9E013.9020804@untamo.net> <Pine.LNX.4.60.0506222345120.13604@agrippa.ukshells.co.uk> <42B9F50B.4000709@untamo.net> <42BA0580.7080105@untamo.net> <42BA0BC1.2050000@untamo.net> <1119491852.26679.549.camel@albedo> <Pine.LNX.4.60.0506231127540.28447@agrippa.ukshells.co.uk>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Paul Kelly wrote:
> >>>> I suspect Brad's recent changes to make G_asprintf() use G_tempfile()
> >>>> should be reverted?
> >>
> >> Yes, it's in G_asprintf(). Simply changing G_tempfile() back to
> >> tmpfile() on line 37 in asprintf.c fixes it. There may be other
> >> consequences so I suggest the maintainer makes the reversion himself in
cvs.
> >
> > This was my doing. I was unaware of the implications of G_tempfile().
> > Can someone back out the changes?
>
> I have changed G_asprintf() back to use tmpfile() instead of G_tempfile()
> and fopen() and it seems to have fixed the r.proj bug.
>
> Probably would need to think about systematically changing some other
> occurences of G_tempfile() as Glynn and Morten suggested.
I agree.
The alternative is to require any program which switches locations
using G__switch_env() to ensure that G_tempfile() doesn't get called
while the location is switched. Given that calls to G_tempfile() could
be hidden deep down in the call graph, that requirement would be
extremely hard to comply with.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Sat, Aug 13 2005
13:03:09
|
|
Status changed to resolved by msieczka
|
|
Sat, Aug 13 2005
13:03:09
|
|
Mail sent by msieczka
|
|
Fixed by Paul Kelly.
All,
That would be practical if you close bugs you have fixed. Thanks.
Maciek |
|