Hi Pavel, On Tue, 2007-01-02 at 16:49 +0200, Pavel Tsekov wrote: > On Tue, 2 Jan 2007, Jindrich Novy wrote: > > On Tue, 2007-01-02 at 16:28 +0200, Pavel Tsekov wrote: > >> On Tue, 2 Jan 2007, Jindrich Novy wrote: > >>> On Sat, 2006-12-30 at 20:51 +0200, Pavel Tsekov wrote: > >>>>> There is an even simpler cure. In mc_tmpdir() when executing > >>>>> the fallback code pass an absolute path to mc_mkstemps(). > >>>>> This will prevent the loop. However I am not yet conviced > >>>>> that this is the best solution. I am still investigating. > >>>> > >>>> I am attaching a patch which passes an absolute path to mc_mkstemps() > >>>> when invoked from mc_tmpdir(). What do you think about this fix ? > >>>> I may add a comment why it is necessary to call mc_mkstemps() with > >>>> an absolute path. By the way I think we should add a check whether > >>>> the environment variable TMPDIR contains an absolute path. Anyway, I'll > >>>> leave this for another patch. > >>> > >>> Thanks for the patch. Do you plan to convert the relative paths to > >>> absolute ones when detected? > >> > >> I think TMPDIR should be ignored in this case. What's your opinion ? > > > > So some hardcoded value such as "/tmp" will then be assumed in case of > > relative path in TMPDIR? > > Btw. does it make sense to use relative TMPDIR ?!
This was the question I asked a few people around in person, the conclusion was that they could imagine a situation when they would use relative TMPDIR, but personally I consider that pretty ugly. So the fallback to a hardcoded value seems to fit here in case of relative path in TMPDIR as it is pretty unlikely to be seen anywhere. Jindrich _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
