Thanks for the reply. You have opened my eyes a little wider. I am still not
sure why the bound files are extracted into a different subdirectory using
the PID in the directory name. The docs led me to believe that if the
"-clean" option was not specified then the extracted files would remain in
the PDK-userID directory. The "-clean" option was to then included the PID
and remove bound files.

The above statements are in reference to using the "-bind" option and not to
PerlApp::extract_bound_file.

From the docs:
--clean

Clean up object files that were extracted from the application at runtime.
By default, these files are cached in the temporary directory. This allows
the next invocation of the app to start up faster.

Are not manually bound files subject to the above described default
behavior?
________________________________________
From: pdk-beta-bounces@[...].com
[mailto:pdk-beta-bounces@[...].com] On Behalf Of Michael
Nacey
Sent: Tuesday, October 12, 2004 3:50 PM
To: PDK-Beta@[...].com
Subject: Re: [PDK-Beta] PerlApp extract bound file problem

Consider the following code:


perlapp.exe  --bind gpl.txt[file=C:\Src\gpl.txt,text,extract,mode=666]
--norunlib Test.pl

## BEGIN CODE (test.pl)
use strict;

print "hi\n";

my $datafile = "gpl.txt";
my $filename = PerlApp::extract_bound_file($datafile);
die "$datafile not bound to application\n" unless defined $filename;
print "\n$filename\n";
print "Go check your temp directory and then type [ENTER] to finish\n";
my $in = <STDIN> ;

## END

This will hold the application open while you look in your temp directory.
According to the documentation in the PDK, the bound file is destroyed after
the script exits.


Bullock, Howard A. wrote: 
Code Correction. itotest-perlapp.opt below was corrected bind statements
referenced wrong files. I apologize for constructing the email during the
debugging session and prior to the finalization test code. 

TEST #1
Script(itotest.pl):

use strict;
print "hi\n";

Options file(itotest-perlapp.opt):

--verbose
--force
--bind notepad.exe[file=c:\winnt\system32\notepad.exe,extract]
--bind junk.pl[file=c:\data\scripts\junk.pl,text,0777]

Compile:

perlapp.exe @itotest-perlapp.opt itotest.pl


My understanding is that without the -clean option is NOT used and the
"extract" option is used on the "bind" line a directory (PDK-userID) should
be created in the user's %temp% directory.  In this directory the binary of
"notepad.exe" should be extracted to this directory.

When I inspect the directory (%temp%) this directory is not created and no
extracted file exists.


TEST #2

When I add the following lines to the script and recompile.

my $name = PerlApp::extract_bound_file('notepad.exe');
print "File: $name  extracted\n";

$name = "C:\DOCUME~1\adminhab\LOCALS~1\Temp\pdk-AdminHAB-2748/notepad.exe"

This seems quite strange as -clean was not specified in the compile so no
PID should be used in the directory name. Regardless the return value from
PerlApp::extract_bound_file seems to be useless as it does not seem to
related to the physical names on disk.

This path is unusable as the two files created are:
48bcd8db11bf5e4f21d5560dd4ab04af.dll
a6eeba928fb0e88bf214579ea961eea5.dll

I think my PDK build 530 behaves the same way, but I have not had a need to
recompile this program since PDK 4.0.

Is this expected behavior? Is there a way to bind a file (Zip) and then
extract it again to the original filename?

Howard A. Bullock
Computer Security
717-810-3584


_______________________________________________
PDK-Beta@[...].com
http://listserv.ActiveState.com/mailman/listinfo/pdk-beta
_______________________________________________
PDK-Beta@[...].com
http://listserv.ActiveState.com/mailman/listinfo/pdk-beta