I read somewhere, though now of course I cannot find the reference, that a
move was being made from the old /usr/tmp to /tmp.
Hope this helps, as it stands currently, utilities such as trad fail without
the /usr/tmp link in place.
A grep for /usr/tmp on today's (February 16, 2005) HEAD and the current
support files gives the following:
rad3R6P1supp
ray/obj/office/anim2.csh:set tempfile=/usr/tmp/pict.$$
ray/obj/office/anim.csh:set tempfile=/usr/tmp/pict.$$
ray/obj/cabin/anim1/script:set tempdir=/usr/tmp/anim1
ray/obj/cabin/anim1/errs:if ( ! -d /usr/tmp/anim1 ) then
ray/obj/cabin/anim1/errs:mkdir /usr/tmp/anim1
ray/obj/cabin/anim1/errs:if ( ! -f /usr/tmp/anim1/583.pic ) then
ray/obj/cabin/anim1/errs:if ( -f /usr/tmp/anim1/583.unf ) then
ray/obj/cabin/anim1/errs:rpict -dr 1 -av .003 .003 .003 -t 3600 -pj .8 -vtv
-vh 60 -vv 49 -x 1024 -y 964 -pa 0 -vp 14.5408 10.9788 4.2 -vd -0.851381
-0.56186 -0.145108 -vu 0 0 1 -z /usr/tmp/anim1/583.z oct/nightcabin
ray/obj/cabin/anim1/errs:mv /usr/tmp/anim1/583.unf /usr/tmp/anim1/583.pic
ray/obj/cabin/anim1/errs:pfilt -1 -x 512 -y 482 -e 120
/usr/tmp/anim1/583.pic
ray/obj/cabin/anim1/errs:ra_t16 /usr/tmp/anim1/583.fin
/usr/tmp/anim1/583.tga
ray/doc/man/cat1/rtrace.1: /usr/tmp/rtXXXXXX common header
information for picture sequence
ray/doc/man/cat1/rpict.1: /usr/tmp/rtXXXXXX common header
information for picture sequence
ray/doc/man/cat1/psort.1: /usr/tmp/psXXXXa /usr/tmp/psXXXXb
ray/doc/man/cat1/pfilt.1: /usr/tmp/rt???
ray/doc/digest/v2n2:10:43pm 114 /usr/tmp/nfotis/ray/obj/office > make
radiance-HEAD
ray/src/util/objline.csh:set d=/usr/tmp/ol$$
ray/src/util/do_file.tcl: if [catch {exec rad -n -w -e $f >&
/usr/tmp/ro[pid]}] {
ray/src/util/do_file.tcl: set curmess [exec cat
/usr/tmp/ro[pid]]
ray/src/util/do_file.tcl: exec rm -f /usr/tmp/ro[pid]
ray/src/util/do_file.tcl: set fi [open /usr/tmp/ro[pid] r]
ray/src/util/do_file.tcl: exec rm -f /usr/tmp/ro[pid]
ray/src/util/do_action.tcl: set rfn /usr/tmp/rf[pid]
ray/src/util/do_action.tcl: set rof /usr/tmp/ro[pid]
ray/src/util/do_action.tcl: set rfn /usr/tmp/rf[pid]
ray/src/util/dayfact.csh: xform -e $genskyf > /usr/tmp/gsf$$
ray/src/util/dayfact.csh: grep '^# gensky ' /usr/tmp/gsf$$
ray/src/util/dayfact.csh: rm -f /usr/tmp/gsf$$
ray/src/util/dayfact.csh: set title=$title\ `sed -n 's/^# gensky
*\([0-9][0-9]* *[0-9][0-9]* *[0-9][0-9.]*\).*$/\1/p' /usr/tmp/gsf$$`
ray/src/util/dayfact.csh: set extamb=`sed -n 's/^# Ground ambient
level: //p' /usr/tmp/gsf$$`
ray/src/util/dayfact.csh: grep -s '^# gensky .* -c' /usr/tmp/gsf$$
ray/src/util/dayfact.csh: rm -f /usr/tmp/gsf$$
ray/src/util/dayfact.csh:set sctemp=/usr/tmp/sc$$.csh
ray/src/util/dayfact.csh: set iltemp=/usr/tmp/il$$.pic
ray/src/util/dayfact.csh:set tltemp=/usr/tmp/tl$$.pic
ray/src/util/dayfact.csh:set dstemp=/usr/tmp/ds$$.pic
ray/src/util/dayfact.csh:set temp1=/usr/tmp/tfa$$
ray/src/util/compamb.csh:set tf=/usr/tmp/ca$$
ray/src/px/xyzimage.csh:set td=/usr/tmp/xyz$$
ray/src/px/vlpic.csh:set tc=/usr/tmp/vl$$.cal
ray/src/px/vlpic.csh:set tp1=/usr/tmp/vl$$r1.pic
ray/src/px/vlpic.csh:set tp2=/usr/tmp/vl$$r2.pic
ray/src/px/vlpic.csh:set tp4=/usr/tmp/vl$$r4.pic
ray/src/px/vlpic.csh:set tp8=/usr/tmp/vl$$r8.pic
ray/src/px/phisto.csh:set tf=/usr/tmp/ph$$
ray/src/px/normpat.csh:set td=/usr/tmp/np$$
ray/src/px/falsecolor.csh:set td=/usr/tmp/fc$$
ray/src/gen/genpine.csh:set tree=/usr/tmp/t$$
ray/src/gen/genpine.csh:set oldtree=/usr/tmp/ot$$
ray/doc/man/man1/rtrace.1:/usr/tmp/rtXXXXXX common header
information for picture sequence
ray/doc/man/man1/rpict.1:/usr/tmp/rtXXXXXX common header
information for picture sequence
ray/doc/man/man1/psort.1:/usr/tmp/psXXXXa /usr/tmp/psXXXXb
ray/doc/man/man1/pfilt.1:/usr/tmp/rt???
Regards
Terry Mc Minn
Faculty of Built Environment, Art and Design
Curtin University of Technology
GPO Box U 1987
Perth 6845
Western Australia
Email: [email protected]
CRICOS Provider Code: 00301J
Hi Terry,
Yes, we did start working to replace /usr/tmp with /tmp, but hadn't gotten around to all the scripts and things. Thanks for the reminder... All we've done so far is change the macro used by C programs to point to /tmp rather than /usr/tmp. I'll get to work on trad and the C-Shell scripts tonight.
-Greg
···
From: Terrance Mc Minn <[email protected]>
Date: February 15, 2005 8:35:01 PM PST
I read somewhere, though now of course I cannot find the reference, that a
move was being made from the old /usr/tmp to /tmp.
Hope this helps, as it stands currently, utilities such as trad fail without
the /usr/tmp link in place.
A grep for /usr/tmp on today's (February 16, 2005) HEAD and the current
support files gives the following:
Greg Ward wrote:
Hi Terry,
Yes, we did start working to replace /usr/tmp with /tmp, but hadn't
gotten around to all the scripts and things.
Thanks for the
reminder... All we've done so far is change the macro used by C
programs to point to /tmp rather than /usr/tmp. I'll get to work on
trad and the C-Shell scripts tonight.
I don't think that all of the C programs use /tmp yet.
What I did a while ago was to add code that would look for
certain directories (depending on platform) and then create
temporary files in the first one found. On posix (unix) systems,
the current sequence is "/var/tmp", "/usr/tmp", "/tmp", ".".
But I haven't had the time to adapt all the programs so they
actually use this code. Consequently, some will find the
alternatives if /usr/tmp is missing or write protected, but
others will still fail. If I remember correctly, then I
changed all the easy cases, where only a string needed to
be replaced. But Radiance does quite tricky things with temp
files in a few places, which will involve more work to update.
So you may get lucky that whatever you need actually works,
but in the general case it's still recommended to have /usr/tmp
available and accessible.
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi Terry,
I just conferred with Schorsch, and I think we've eliminated use of the /usr/tmp directory in tomorrow's HEAD release. In most cases, we aren't searching for a temp directory, just using /tmp and hoping it's there. This is at least an improvement from assuming /usr/tmp is available, but not as robust as the searching method Schorsch is working on.
-Greg
···
From: Georg Mischler <[email protected]>
Date: February 16, 2005 3:42:03 AM PST
Greg Ward wrote:
Hi Terry,
Yes, we did start working to replace /usr/tmp with /tmp, but hadn't
gotten around to all the scripts and things.
Thanks for the
reminder... All we've done so far is change the macro used by C
programs to point to /tmp rather than /usr/tmp. I'll get to work on
trad and the C-Shell scripts tonight.
I don't think that all of the C programs use /tmp yet.
What I did a while ago was to add code that would look for
certain directories (depending on platform) and then create
temporary files in the first one found. On posix (unix) systems,
the current sequence is "/var/tmp", "/usr/tmp", "/tmp", ".".
But I haven't had the time to adapt all the programs so they
actually use this code. Consequently, some will find the
alternatives if /usr/tmp is missing or write protected, but
others will still fail. If I remember correctly, then I
changed all the easy cases, where only a string needed to
be replaced. But Radiance does quite tricky things with temp
files in a few places, which will involve more work to update.
So you may get lucky that whatever you need actually works,
but in the general case it's still recommended to have /usr/tmp
available and accessible.
-schorsch
Hi Greg and Georg,
I guess related to this topic. I know that there are compiler warnings that crop up with respect to the use of "mktemp" being dangerous and recomending the use of "mkstemp", is this something that needs to be be treated or not?
-Jack
Greg Ward wrote:
···
Hi Terry,
I just conferred with Schorsch, and I think we've eliminated use of the /usr/tmp directory in tomorrow's HEAD release. In most cases, we aren't searching for a temp directory, just using /tmp and hoping it's there. This is at least an improvement from assuming /usr/tmp is available, but not as robust as the searching method Schorsch is working on.
-Greg
From: Georg Mischler <[email protected]>
Date: February 16, 2005 3:42:03 AM PST
Greg Ward wrote:
Hi Terry,
Yes, we did start working to replace /usr/tmp with /tmp, but hadn't
gotten around to all the scripts and things.
Thanks for the
reminder... All we've done so far is change the macro used by C
programs to point to /tmp rather than /usr/tmp. I'll get to work on
trad and the C-Shell scripts tonight.
I don't think that all of the C programs use /tmp yet.
What I did a while ago was to add code that would look for
certain directories (depending on platform) and then create
temporary files in the first one found. On posix (unix) systems,
the current sequence is "/var/tmp", "/usr/tmp", "/tmp", ".".
But I haven't had the time to adapt all the programs so they
actually use this code. Consequently, some will find the
alternatives if /usr/tmp is missing or write protected, but
others will still fail. If I remember correctly, then I
changed all the easy cases, where only a string needed to
be replaced. But Radiance does quite tricky things with temp
files in a few places, which will involve more work to update.
So you may get lucky that whatever you need actually works,
but in the general case it's still recommended to have /usr/tmp
available and accessible.
-schorsch
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Jack,
The reason for the mktemp() warning is that you can end up with a race condition if you have multiple processes trying to create temporary files using the same template, which is probably something we don't particularly need to worry about. Unless you have a lot of processes running in parallel and creating temp files like mad, the chances of a collision are extremely remote. Altering the code to use mkstemp() in some places is impossible, and in other places is just a lot of work. In 20 years of using the software, I haven't run across a problem related to temp file collisions, so I'm tempted to ignore it.
-Greg
P.S. to Francisco -- I used a command very like this to identify files to change, and changed them. Thanks.
···
From: Jack de Valpine <[email protected]>
Date: February 16, 2005 9:28:41 AM PST
Hi Greg and Georg,
I guess related to this topic. I know that there are compiler warnings that crop up with respect to the use of "mktemp" being dangerous and recomending the use of "mkstemp", is this something that needs to be be treated or not?
-Jack
A P.S. to my last message -- mktemp() uses the process ID as part of the "magic number" used to name the temp file, making collisions among competing processes on the same machine impossible. It's really only when a single process is multithreading that one needs to worry, and Radiance doesn't use threads. Different machines with potentially colliding process id's could be a problem, but again it is extremely unlikely, especially when the files are being created in the /tmp directory, which is usually local to each machine.
-G
···
From: Jack de Valpine <[email protected]>
Date: February 16, 2005 9:28:41 AM PST
Hi Greg and Georg,
I guess related to this topic. I know that there are compiler warnings that crop up with respect to the use of "mktemp" being dangerous and recomending the use of "mkstemp", is this something that needs to be be treated or not?
-Jack
Hey Greg,
Ok, this makes sense, thanks for the explaination.
-Jack
Greg Ward wrote:
···
A P.S. to my last message -- mktemp() uses the process ID as part of the "magic number" used to name the temp file, making collisions among competing processes on the same machine impossible. It's really only when a single process is multithreading that one needs to worry, and Radiance doesn't use threads. Different machines with potentially colliding process id's could be a problem, but again it is extremely unlikely, especially when the files are being created in the /tmp directory, which is usually local to each machine.
-G
From: Jack de Valpine <[email protected]>
Date: February 16, 2005 9:28:41 AM PST
Hi Greg and Georg,
I guess related to this topic. I know that there are compiler warnings that crop up with respect to the use of "mktemp" being dangerous and recomending the use of "mkstemp", is this something that needs to be be treated or not?
-Jack
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Greg Ward wrote:
Hi Jack,
The reason for the mktemp() warning is that you can end up with a race
condition if you have multiple processes trying to create temporary
files using the same template, which is probably something we don't
particularly need to worry about.
Chances of this causing problems accidentally are remote.
The real reason why the compiler warns about it is that in
very specific scenarios it can be exploited maliciously.
The problem is that the generated names are predictable, and
a rogue process can create eg. a symbolic link where the file
is going to be opened. If done right, then this makes it
possible for a user process to write to files that would
normally only be writeable with root priviledges. Don't ask
me for the exact method, I'd have to look that up too...
For software not running as root, this is mostly of academic
interest. The worst thing an "attacker" could do to you is
corrupt your temp files, thus invalidating your simulation.
Anyone having enough access (a normal user account) on your
system to try this will have many other ways to harm you
with a lot less effort.
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
My QA experience says that often as not, this means that it will
happens often as not. 
Randolph
···
On Wed, Feb 16, 2005 at 01:07:31PM -0500, Georg Mischler wrote:
Greg Ward wrote:
> Hi Jack,
>
> The reason for the mktemp() warning is that you can end up with a race
> condition if you have multiple processes trying to create temporary
> files using the same template, which is probably something we don't
> particularly need to worry about.
Chances of this causing problems accidentally are remote.
Given the U.S.'s flouting of the Kyoto Protocol, I expect we'll all be underwater before there's a collision of temp files in Radiance....
-G
···
From: Randolph Fritz <[email protected]>
Date: February 16, 2005 5:05:24 PM PST
On Wed, Feb 16, 2005 at 01:07:31PM -0500, Georg Mischler wrote:
Greg Ward wrote:
Hi Jack,
The reason for the mktemp() warning is that you can end up with a race
condition if you have multiple processes trying to create temporary
files using the same template, which is probably something we don't
particularly need to worry about.
Chances of this causing problems accidentally are remote.
My QA experience says that often as not, this means that it will
happens often as not.
Randolph
