On approximately 1/1/2004 7:38 PM, came the following characters from the keyboard of Autrijus Tang:
å ä, 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.
Aha. OK, I had one misconception in my thinking... I was thinking about the PAR temp directory as being for program data, but really it is for pieces of the program code. The program itself (the perl script being packaged) should determine its data storage location on its own.
For auxiliary program data, unpacking the scripts and dlls, a directory tree under c:\program files would be fine (if that is where the .exe is). So in fact, it seems it would be quite acceptable to do the following, and only the following:
1) Determine the directory in which the packaged script exists. This comes from argv[0], generally. Example: Packaged script located in c:\program files\morbus software\amphetadesk.exe The directory identified would be c:\program files\morbus software
2) In that directory, create a subdirectory with the name of the packaged script, and its EXEID (for version control). The EXEID can be the timestamp YYYYMMDDHHMMSS that the script was packaged, as was noted in another subthread of this discussion. Example: the subdirectory created would be c:\program files\morbus software\amphetadesk-20030101201103\ I'll call it c:\pf\ms\a for short, in the rest of the examples.
3) use the newly created subdirectory to unpack files into. The following algorithm avoids clobbering:
3a: create a lock file c:\pf\ms\a\unpacking.lock
if the creation succeeded, then:
3b: decompress/unpack all the other files into c:\pf\ms\a
3c: remove the lock file c:\pf\ms\a\unpacking.lock
else
3d: sleep for 1 second
3e: if the number of times this step has been reached exceeds some threshhold settable by the packager, tell the user that the program will exit, he should remove the directory c:\pf\ms\a, and try again... but to check for other possible users of the program running concurrently.
3f: if the lock file still exists, goto step 3d:
endif
3g: launch the unpacked script.
I suppose that builds in the assumption that in a multi-user system, that all the decompressed, unpacked files will be given security settings allowing other users to read them. Can that be enforced? If not, then adding $USER to the amphetadesk-YYYYMMDDHHMMSS directory might be necessary. All these files should be able to be marked read-only, by everyone, in most cases I can think of, or given the same security settings as the original, packaged script .exe file?
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.
I'm not so sure how you bulid the compiled .exe file.
Somehow you unpack the other files, so your .exe is reading the .exe to obtain those other files. Can you unpack a file to memory, without writing it to disk?
If so, you could use a special configuration file inside the package, and the .exe would read that configuration file first, and then use the settings to control the unpacking of the rest of the files to disk.
If not, then you could, in the .exe, if you own the source to it, place constant C strings such as:
char config[] = "HERE IS THE CONFIGURATION\n" "configparam1='' \n" "configparam2='' \n"
etc.
Where '' surround the actual value, and there are enough spaces left to hold the maximum length value of the parameter. Then your packaging script could read the executable in binary, find the HERE IS THE CONFIGURATION string, and parse and modify data for the parameters. This technique is a bit grungier than the first one, of course.
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. :-)
If you document those values as either needing to exist, or being single level directories, then all should be fine, eh?
Thanks, /Autrijus/
You mentioned in another message that CLEARTEMP defaults to 0 in PerlApp. If this means that clearing does not automatically happen, I would think, that for program components such as would be unpacked by PAR, that that would be appropriate... leave it around for the next execution to be faster, unless the user or packager overrides the setting. For each configuration setting, the packager should have the option to set the default, and determine if the default may or may not be overridden at runtime via some environment variable.
-- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
