It's all in the archive at http://www.mail-archive.com/[EMAIL PROTECTED]/msg01149.html
Solution was to remove the bribes package, and install from the PAR site instead. (I think the problem is in parl.exe)
Rick.
Vlad Harchev wrote:
Hello,
I'm using ActiveState Perl 5.6.1 (the one available currently) and PAR-0.80 (precompiled from bribes.org), on WinXP.
It turns out that sometimes when I run the same .exe file produced by PAR,
it tries to create directories with suspicious names (containing non-alphadigital (or even non-ascii!) char at the 2nd position from the end).
Sometimes that character is even illegal for filenames, so running .exe fails at the unpacking stage!
E.g.:
G:/TMP/par-tests/was/1.exe: creation of J:\DOCUME~1\hvv\LOCALS~1\Temp\par-hvv\cache-5aec05dac5668209fe6c0c35fca8bfb1875967b3?:2/perl56.dll failed - aborting with 2.
The funny problem is - if I run the same .exe file e.g. 100 times (if I'm lucky not getting illegal character for filenames during these 100 runs), the directory J:\DOCUME~1\hvv\LOCALS~1\Temp\par-hvv\ will contain directories like these
cache-5aec05dac5668209fe6c0c35fca8bfb1875967b3?(2
cache-5aec05dac5668209fe6c0c35fca8bfb1875967b3?B2
cache-5aec05dac5668209fe6c0c35fca8bfb1875967b3?.2
- i.e. differing only in at most 2 trailing characters! The number of such directories will be less than 100.
The other funny thing is that files from only one of these directories
are used - if I make changes to files in other cache directories, these changes don't affect ANYTHING - so par, even creates sometimes NEW cache directories, it DOESN'T USE them!
Another funny thing is "stability" of chosing the garbage suffix - if I run .exe file and get
G:/TMP/par-tests/was/1.exe: creation of J:\DOCUME~1\hvv\LOCALS~1\Temp\par-hvv\cache-5aec05dac5668209fe6c0c35fca8bfb1875967b3?:2/perl56.dll failed - aborting with 2.
- then I will be getting this error forever. If I run any other application (in hopes the random memory fragment from which that garbage appear to com will get more "lucky" content), it changes only 3rd character from the end (it turns in other non-ascii character), but invalid 2nd character from the end doesn't change.. It seems only rebooting fixes the problem sometimes.
Precompiled PAR-0.80 from bribes.org on Perl-5.8.3 (the build that is available on ActiveState.com right now) (mis)behaves the same way. No problem on Linux though.
Again, the usual questions: * Does anybody experience the same problems (and whether one was able to overcome them - and how)? * what file and function generates those names? * Is it fixed in development version of PAR?
