XCopy locks temp directory

[Rod Green]

Let me get to the point of my problem, and then explain the details.

Xcopy seems to lock the SCRDIR so I cannot remove the directory later.

Now the details:
I have written an install that determines the currently installed files
on the workstation, and then replaces ONLY the files that exist with
newer ones from the media. I had to write my own because IS does not
have a function or component file attribute to only copy files if they
exist on the target (like having an IFEXISTS property with
ALWAYSOVERWRITE, and NEWERDATE) .

To get around this, I copy the files from the media to a temp directory
and set this as my SRCDIR. I then determine the files already in the
TARGETDIR and run XCopy for each installed file, from the SRCDIR to the
TARGETDIR, and replace the existing files. Everything is working fine,
except when I try to remove the temp directory. Xcopy seems to have some
kind of lock on the directory that does not allow me to delete it.

At the end of the install (in CleanUpInstall) I try to remove the
directory with the following:
ChangeDirectory (TARGETDIR); // change to the directory
above the temp directory
if (Is (PATH_EXISTS, TARGETDIR ^ "Temp") = TRUE) then
DeleteDir(TARGETDIR ^ "Temp", ALLCONTENTS); // delete the temp
directory
endif;

All of the files get removed from the directory, but the directory does
not get deleted. Even if I try to delete the directory manually after
the
install has finished (sitting at SdFinish dialog), I get a "Sharing
violation. The source or destination file may be in use".
It is not until the setup exits completely that I am able to manually
delete the directory.
(NOTE: If I comment out the XCopy command, the directory does get
deleted.)

I have tried using the CopyFile command, and changing directory
(ChangeDirectory) before deleting, but nothing seems to work.

Any suggestions?

Rod Green
Ameritech Library Services
r...@amlibs.com

BTW, I am using IS5 International build 147.

[Stefan Krüger]

Rod,
create your temp directory under SUPPORTDIR. Then InstallShield will do the
clean-up for you.

Stefan Krueger

The reply-to address in the message header is invalid.
If you want to contact me directly, please mail to:
skru...@usa.net

*** InstallSite - Free resources for setup developers
*** http://www.ibv-tools.de

Rod Green schrieb in Nachricht <35EAE3F6...@amlibs.com>...

[Rod Green]

Hi Stefan,
Thanks for your suggestion, but it still does not work. Now the _istmp0.dir
directory is still there with a "Temp" directory under it after the setup has
been closed. There is something that XCopy is doing to the directory, or
keeping resident in the directory after it has run.

If you have some spare time (yeh right), try the following:

Create two directories on your C:\ drive, called XCopyScr and XCopyTar and copy
any text file into the XCopySrc directory as Test.txt. Try the following code.
The results will be that the file will copy correctly to C:\XCopyTar, and the
file will be deleted from C:\XCopySrc, however the directory will still
exist.If you manually try to delete the directory while the setup is still
running (during the DeleteDir error), you will get an error from Windows. Not
until the setup has completely closed will you be able to remove C:\XCopySRC.

function XCopyExample ()
begin
// XCopy file
VarSave (SRCTARGETDIR);
SRCDIR = "c:\\XCopySrc";
TARGETDIR = "c:\\XCopyTar";
if (XCopyFile ("test.txt", "", COMP_UPDATE_DATE) < 0) then
MessageBox ("XCopy Failed", INFORMATION);
endif;
VarRestore (SRCTARGETDIR);

// Delete directory
if (DeleteDir("c:\\XCopySrc", ALLCONTENTS) < 0) then
MessageBox ("DeleteDir Error", INFORMATION);
endif;
end;

I have, however, found a kludge that seems to allow the directory to be
deleted. If I do another XCopyFiles from a different directory, it appears to
"unlock" the original directory so it can be deleted.

// Kludge to fix DeleteDir error
VarSave (SRCTARGETDIR);
SRCDIR = SRCDISK;
XCopyFile (svItem, "", COMP_UPDATE_DATE);
VarRestore (SRCTARGETDIR);

Maybe I should forward this on to IS, or maybe I'll just work around it like
most other problems I have.

Thanks for your help.

Rod Green
Ameritech Library Services
r...@amlibs.com