å ä, 2004-01-02 07:27, Morbus Iff åéï > Are we talking about multiple copies running at the same time?
Yes. Suppose the user launches four copies of a.exe almost
simultaneously, under PAR_CLEARTEMP=1. If they all write to the same
directory with the same filenames, then the first a.exe exiting will
clobber the files for all other still-running instances.
> Why not a simple increment?
> $TEMP/output1, output2, output3, etc.
I have no simple way to increment them atomically (i.e. in a way that
can avoid race conditions), save perhaps to try mkdir() on each number
until one succeeds, and then simply use it.
But with that scheme, once output1 is exited and cleaned up... Should we
re-use output1 next time? Then there is no simple relation between the
numbers and the proccesses.
> See, I dunno. A "temp" directory, to me, signifies that the files are there
> temporarily. If a "temp" directory is used to keep files around until
> they're deleted by some other force (an end-user, for example), that's not
> very temporary - why should I force the user to clean up after my app?
Right. I just mentioned in the other mail about calling it a "cache"
directory instead.
> In this regards, "CLEARTEMP" is redundant: shouldn't temp directories be
> cleared anyways?
The idea springs from the desire of re-using previously extracted DLL
and module files, so people running a large .exe file can avoid
decompression altogether. Also, as you noted, to keep the executable
path identical across runs when PAR_TEMP is not set, for the
conveninence of firewall/virus scanners.
> Is anyone currently depending on the abilities for a
> temp directory to exist unchanged between PAR'd runs?
Probably not, so I'm willing to be convinced that we do not need such a
feature at all. :-)
> $EXEID, I'd use "build-date in seconds", if possible:
Sounds sane. Thanks!
> This sounds sane (ignoring my questions about "the real issue", but I'd
> really want something I could build into the compiled .exe, that isn't
> determined by the user's environment.
I really want that too. However I see no easy places to put the
configurations inside the compiled .exe... I'll keep thinking about
that.
> At runtime, no $ENV: $TEMP/par-$USER-$EXEID, clean at BEGIN/END.
This should probably not clean itself, as its name is now:
$TEMP/par-$USER/cache-$EXEID
> At runtime, $PAR_TEMP: use that directory, no cleaning.
> At runtime, $PAR_CLEARTEMP: use $TEMP/par-$PID, clean at BEGIN/END.
> At runtime, $PAR_TEMP/CLEARTEMP: use that directory, clean at BEGIN/END.
Those sounds sane. :-)
Also, if you name your $PAR_TEMP as
internals
it will always work. The reason why
data\internals
sometimes break is the "data\" path does not exist on the current
directory -- and my C-fu is so bad that I don't know exactly how to
write the equivalent code as "FIle::Path::mkpath".
If you think creating intermediate directories to $PAR_TEMP is
important, pointers to ready-made, cross-platform mkpath() code is most
welcome. :-)
Thanks,
/Autrijus/
signature.asc
Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
