>> b) The name of the temp directory was based off the process ID of >> the running application. I believe that this decision was made >> to stop the application from clobbering old versions that were >> not properly deleted from the tmpdir (is this right?). > >Correct. And also to prevent files from different >users from stepping over each other.
Please forgive my ignorance. From an unknowing standpoint, it looks like we're talking about a workaround to a bug? Could I get more history on this? I mean, if files aren't being properly deleted from the $TEMP directory, shouldn't we find out why they're not getting properly deleted instead, and not spend time developing workarounds? Are we talking about multiple copies running at the same time? Why not a simple increment? $TEMP/output1, output2, output3, etc. >Currently, setting up a AmphetaDesk.bat that says: > mkdir C:\AmphetaDesk\data > set PAR_TEMP=C:\AmphetaDesk\data\internal > C:\AmphetaDesk\AmphetaDesk.exe >seems to work for me. This isn't truly ideal for me: * it assumes that I know the final location of the user's AmphetaDesk directory once it's installed on their machine. * if I don't, it assumes that I'll use some sort of installer that will find out where the user is installing the app, then create the batch file for the user (AmphetaDesk currently uses no installer: you just unzip it and go). * if I don't use an installer, it assumes the user knows enough to open up a demo batch file in a normal text editor, to properly specify their path, and to not modify any other lines. >- If PAR_TEMP is specified, use it as the working directory (the > one to store temporary files), and never clean up that directory > after exiting, to avoid race conditions. > >- If PAR_TEMP is not set, look at PAR_CLEARTEMP to determine > whether to clean up after existing: > > - If yes, use $TEMP\par-$PID\ as the working directory, > cleaning it both before and after execution. 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? In this regards, "CLEARTEMP" is redundant: shouldn't temp directories be cleared anyways? This, again, goes back to my ignorance about the real issue: why $PID was needed instead of properly deleting the files in the first place. Is anyone currently depending on the abilities for a temp directory to exist unchanged between PAR'd runs? > - If no, use $TEMP\par-$USER-$EXEID\ as working directory, > reusing any existing files inside. (The default case) > >The $EXEID should be something that differs from one executable to >another; maybe its basename + size, maybe something else. This is to >prevent exe files with different Perl58.dll from clobbering each other. $EXEID, I'd use "build-date in seconds", if possible: * I have one client-requested script that I currently build .exe's from. * The ONLY thing that differs between the .exe's is a date string and a three-digit user prefix. These strings are not configurable OUTSIDE the source code because the "deal" between the client and I is to charge per app - configuration outside the app would allow the client, in essence, to build his own. * The app's are always named the same. Because the only things that differ between the .exe's are strings that remain the exact same size, basename+size would not work. I vote for "time compiled in seconds", because that'd require some extensive forethought to try and break: a fast computer issuing multiple compiles of the same script for the same OS at the same moment. >So, by default, the same AmphetaDesk.exe should always get executed in >the same directory. Does it sound sane for you all? 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. Here is what I want: # as per your thoughts: use $TEMP/par-$USER-EXEID, and # clean up the existing files inside at BEGIN/END. pp -o AmphetaDesk.exe AmphetaDesk.pl # as per your thoughts: use $TEMP/par-$PID, and # clean up the existing files inside at BEGIN/END. pp -o AmphetaDesk.exe -cleartemp AmphetaDesk.pl # where-ever the .exe ends up, assume a data/internal # directory exists. if it doesn't, create it automatically. # no cleaning at BEGIN/END. pp -o AmphetaDesk.exe -temp data/internal AmphetaDesk.pl # where-ever the .exe ends up, assume a data/internal # directory exists. if it doesn't, create it automatically. # since "cleartemp" is set, we cleanup at BEGIN/END. pp -o AmphetaDesk.exe -temp data/internal -cleartemp AmphetaDesk.pl Since the options are to pp, they'd be internal to the .exe, not dependent on anything from the environment (save $TEMP and $USER, where needed). At runtime, no $ENV: $TEMP/par-$USER-$EXEID, clean at BEGIN/END. 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. -- Morbus Iff ( *splutch* ... /me respawns ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
