>> # 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
>
>It is not clear to me why par-$USER-EXEID would be used sometimes, and
>par-$PID would be used sometimes. Seems like the latter is more unique
>over time, if a single user can run multiple copies of the same par .exe
I wasn't, and even with some off-list explanations, 100% clear on why it
was either, but it has something to do with runtimes and differing versions
of the same .exe (perhaps one built for 5.6.1 and another for 5.8.0).
Example:
* Consider one program run twice, at the same time. If the first
instance extracts to one temp directory with all it's files and
begins running, and then the second instance extracts to THE
SAME directory (as per the first example, above), then problems
will occur: the first instance will start seeing "new" second
instance files, and the second instance will (possibly) see
first instance files that shouldn't (yet) exist.
In re-looking at the above, however, -cleartemp (whether my proposal
or Autrijus' initial suggestion) doesn't immediately suggest *any*
reason why behavior would change from $USER-$EXEID to $PID. Nor does
it suggest how -cleartemp is any different than the proposed default.
At 6:16 PM -0800 1/1/04, Glenn Linderman wrote:
>This data/internal thing... really, if AmphetaDesk.exe (per the example)
>is installed in c:\Program Files\somewhere, then data/internal should
>not be placed underneath it. It is dynamic user data, and should be
>placed (per Windows recommendations) under c:\Documents and
>Settings\user\Application Data\somewhere\data\internal where
There's a slight difference. AmphetaDesk doesn't currently use ANY
temp directory whatsoever: when I'm talking about "data/internal" above,
I'm talking as MERELY a substitute to $TEMP, which can be heartily
assumed to be "outside" an "AmphetaDesk" directory. At this point,
AmphetaDesk stores all user data under $Bin/data/ which, yes, I do heartily
consider a bug (and I've already got patch code that sanely determines
the proper $HOME directory on all versions of Windows, Mac, and Linux).
That code will probably end up in the nextish version of AmphetaDesk,
but, in retrospect, will cause problems with the proposed PAR scheme
anyways:
* AmphetaDesk runs on all versions of Windows, including 95.
* Not all versions of Windows set a $HOME dir (before multi-user).
* There's been roughly 50 messages on the topic, and the current
proposed patch for Windows is something like this:
$base = '\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\';
$dir = _get_reg_value($base . 'Shell Folders\\', 'AppData')
|| _get_reg_value($base . 'User Shell Folders\\', 'AppData')
|| _get_reg_value($base . 'Shell Folders\\', 'Personal')
|| _get_reg_value($base . 'User Shell Folders\\', 'Personal');
* To allow the user choice, he can set $AMPHETADESK_HOME.
None of the above, which require runtime determination not compile-time,
would be workable with any of the proposed PAR temp things. However,
ignoring what I'd do in that case as a solution, I'd still need some way to
depend on ONE single location for the temp directory, merely to get past
the firewall notices. With that in mind, I heartily support the idea
of $TEMP/par-$USER-$EXEID with cleaning on BEGIN/END (clobbering,
at least in my ignorance, wouldn't be an issue, since AmphetaDesk
uses only stuff within it's $FindBin::Bin directory).
>If $ENV{APPDATA} doesn't exist (Windows pre 2000), then the installation
>location of the .exe is probably an appropriate prefix for the path, as
>is suggested here (the rules were different on Win9x; not sure what they
The original planned behavior, with an eye toward upgrading users, was "if
we can find user data in $Bin/data, we'll keep using it there, and issue an
optional suggestion to move it to $determined_homedir". If $Bin/data is
not there, then we use $determined_homedir as any proper program should.
I will probably, however, issue an AmphetaDesk 1.0 that contains NO
backwards compatibility (seriously, AmphetaDesk has been out since
2001 with an eye towards backwards compat - I think it's time to
throw out some old crufty code that's keeping things in check).
--
Morbus Iff ( earth? shxt and scrambled eggs. earth? )
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
