Details Ticket 3362


Comment | Reply | Take | Open


Serial Number 3362
Subject r.proj works ONLY when source and target mapset names are identical
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Sat Aug 13 13:03:09 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sat Aug 13 13:03:09 2005 (3 yr ago)
Created Tue Jun 21 19:29:57 2005 (3 yr ago)

Transaction History Ticket 3362


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
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request