I do not think the Control-L in the path problem is the same as the one Rick is describing. >dll failed - aborting with 2 System error 2 is "No such file or directory" so the Control-L in the cache path name is a problem, but not the same one.
----- Original Message ----- From: "the.noonings" <[EMAIL PROTECTED]> To: "Alan Stewart" <[EMAIL PROTECTED]>; "Rick Fitzsimmons" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, April 08, 2004 9:04 AM Subject: Re: PAR0.80 on Win32 - problem with cache directories > Good and bad, > > On Windows XP Pro and Windows XP Home, it works. On Windows 95, I get a > Control-L character in the cache path name. In the paste below you cannot > see the Control-L. It is showing as an unprintable character in the > directory "C:\WINDOWS\TEMP\par-Control-L". > > C:\MYDOCU~1\MALCOLM\EZBACKUP.EXE: creation of > C:\WINDOWS\TEMP\par- \cache-497442cbc970760590b3ad5834c3c9e9e0d80528/perl58. > dll failed - aborting with 2. > > ----- Original Message ----- > From: "Alan Stewart" <[EMAIL PROTECTED]> > To: "Rick Fitzsimmons" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, April 07, 2004 9:46 PM > Subject: Re: PAR0.80 on Win32 - problem with cache directories > > > > On 7 Apr 2004 at 22:41, Rick Fitzsimmons wrote: > > > > > Hi, > > > Been having problems since updating to 0.80. One user gets error message > > > with Windows 2000 [Version 5.00.2195] when running a pp'd executable, > > > but another user has no trouble at all. After many attempts, I've also > > > seen this happen myself on WinXP [Version 5.1.2600] > > > > > > Typical error message is: > > > parser: creation of > > > > C:\DOCUME~1\greya\LOCALS~1\Temp\par-greya\cache-829e1673cd0100b0bd0dac81628e > 04265e166964?<//perl58.dll > > > failed - aborting with 2. > > > (The pp'd executable is parser.exe) > > > > The characters ?<// should be just one / path character. > > > > Looks like it failed in static.c, after creating the temp directory with > no error, but > > when it tried to open a file there to extract perl58.dll in it. After this > crash, does > > the directory: > > > > > C:\DOCUME~1\greya\LOCALS~1\Temp\par-greya\cache829e1673cd0100b0bd0dac81628e0 > 4265e166964 > > > > exist? If it does, I presume it does not have any characters after the > ...66964 at the > > end. I wonder if this is the SHA-1 algorithm blowing up or something else. > > > > > > > > What puzzles me is the extra characters after the SHA-1 hash, and I > > > wonder if these are causing a problem. There always seem to be three > > > extra characters after the 40-hex-digit hash value, and they are often > > > not valid filename characters. > > > > What other character combos have you seen besides ?<// > > > > > > > > As a workaround, I've tried setting the PAR_GLOBAL_TEMP environment > > > variable, but then it fails with the error message: > > > IO error: opening P*2.exe for read : Invalid argument > > > at -e line 164 > > > Can't call method "extractTree" on an undefined value at > > > ../blib/lib/PAR.pm line 263. > > > > > > Can anyone explain what's going wrong? > > > > > > Has anyone managed to use PAR_GLOBAL_TEMP successfully on Win32? > > > > > > > I've used it on XP and NT. What did you set PAR_GLOBAL_TEMP to? > > > > Also, what options did you run pp with to generate parser.exe? > > > > > > >
