Devin said:
Thank you all for replying.
As for details.. I'm trying to run the file/encryption program,
TrueCrypt, from memory again. I use it to encrypt data on my USB
drive.
Sorry if the explanation is long but here it is anyway.
Environment setup and usage:
i) two partitions created - one is open and the other is close
(encrypted).
ii) TrueCrypt.exe reside on the open partition so it is possible for
me to access the encrypted partition anywhere by mounting it to an
available drive letter.
iii) after successful mount, there's an encrypted file within the
(encrypted) partition, which I need to mount as well.
I take it, then, that when the encrypted partition is available, the open
one is not. If that is not the case, I would have the second script find the
executable by looking wherever it might be located (as someone already
suggested. Alternately, you could have the first script create the second
script in the %temp% folder. If the first script knows where the executable
is, it could create that second script with the full path included.
Two simple scripts for :
i) mounting encrypted partition (1st stage) - reside on open or local
partition
ii) mounting encrypted file (2nd stage) - reside within the encrypted
partition
Script content :
1st stage
start "" TrueCrypt.exe /quit background /volume "\Device
\Harddisk1\Partition2" /letter X
2nd stage
start "" TrueCrypt.exe /quit background /volume "X:
\EncryptedFile.tc" /letter Z
To run second script (for mounting encrypted file), I need to either:
i) create another copy of original executable to be inside the same
folder where the script reside. Disadvantage: version conflict will
happen if I forget to update the copy after updating the original (on
USB device's open partition) and mounting with the latest version.
Not an issue if the copy is made each time the first script runs...
Tiring to remember which copies require updating.
2) hardcoded the executable path on open partition. Disadvantage:
path can break since the USB's drive letter for open partition can
vary.
3) hardcoded the executable path on local partition (i.e. C drive).
Disadvantage: portability lost
I'd like to explore ways that will allow me to :
a) maintain portability
b) require no hardcoded path
c) reduce/avoid creating multiple copies of TrueCrypt.exe
Now back to my original post:
If I am able to re-rerun TrueCrypt.exe from memory again for stage 2,
it will help me deal with b) and c) above.
IMHO, this cannot be done.
First, I would assume that truecrypt does not stay resident, but does its
work and then terminates. If so, the memory it occupied would be released
back to the O/S, so you could never be sure that an intact copy of the
program still existed in memory.
Second, even if it did remain in memory, it would be a copy that had already
run. Its data storage might not be re-initialized to what it was when first
loaded from its .exe file.
Third, since the only batch commands that allow you to run a program get
that program from an executable file, the only way you could "re-run" a
program still in memory would be to write a program that would find the
program in memory, optionally initialize its storage (wherever that might
be), and be prepared to provide the command-line parameters corresponding to
the second invocation to the program.
And those are only the few issues I could think of late on a work night! ;-)
But it seems to me that the third option would be far more work to develop
(and, yes, your script would need to know where to find this executable)
than finding a way for the first script to provide the required path to the
second.
/Al
