[GRASS5] [bug #3362] (grass) r.proj works ONLY when source and target mapset names are identical

[Morten Hulden]

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