Files in TMP-Dir after compile

[NewsArchive]

Hi Friedrich,

after every compilation of my project, there left two files in my temp
folder (see attached screen shot). How can I force DB7 to clean up its
files?

Thanks for your answer.

Markus

[NewsArchive]

Hi Markus,

> after every compilation of my project, there left two files in my temp
> folder (see attached screen shot). How can I force DB7 to clean up its
> files?

As far as I know, the compiler does not use the temporary Windows folder. I
checked this here (compiled a large project) on XP, Win7 and Win8 and there
were no files created in the temp folder.

Friedrich

[NewsArchive]

Hi friedrich,

It's caused by the "#zip file(s)" compiler directive.

Markus

[NewsArchive]

No, it's not. Sorry.

Markus Zander

[NewsArchive]

>
> No, it's not. Sorry.
>

I think the (~ file) is a file from your protection software product. And
the LSB9E17.tmp is from a previous installer crash (or your protection
software locked it in such a way that it was not possible to remove it at
installer runtime).

Friedrich

[NewsArchive]

Hi Markus,

>
> It's caused by the "#zip file(s)" compiler directive.
>

Hmm, I don't see this here. First of all, the ZIP directive will never
create a file similar to LSB9E17.tmp (LSB = Linder Setup Builder).

The ZIP directive creates a file in form of LSZ1530.tmp (LSZ = LSZip) and
deletes it after the compilation process!

Perhaps your virus-scanner creates the file beginning with "~"? It's
possible that an installer crash leaves a LSB file in the temporary Windows
folder.

Friedrich

[NewsArchive]

OK, this is waht I've found:

1.) A file ~??????????????????.TMP is created, when I start SB7 and
deleted, when I close SB. I have no Idea where this file comes from, but
because the file is removed, when I close sb7, even if I kill the
process via task manager.

2.) When I run my setup, there is a LSB*.tmp file generated in the temp
folder and not deleted, if the setup has finished. You can reproduce
this with an absolutly blank Install script. Sysinternals processmonitor
shows "CANNOT DELETE". Even when I disable my AV-product.

What can we do about this?

Markus

p.s.: I thought, it was the compile process, because I call a little
helper exe from my script.

[NewsArchive]

>
> What can we do about this?
>

Well, ask your anti-spyware or anti-virus vendor(s) <g>. I believe that it
is not fully disabled even if you disable it. And make sure that you do not
have a virus on your system!

When you start SB and then "kill" it via task manager and you see a file
being created and removed tells you that SB did not create nor remove it ;-)
If you kill SB then it can't remove its files because you killed the
process! In other words, another process monitors something in the
background.

Just for fun, run a SetupBuilder created setup.exe on a clean virtual
machine and you'll see that it will not leave back file(s). This is
definitely not caused by SetupBuilder.

BTW, we compile and run/test 300+ projects per day on several machines.
There is not a single SetupBuilder created temporary file left on any
machine.

Friedrich

[NewsArchive]

Just for fun, see attached screenshots.

Test app executed. The SetupBuilder application generates some temporary
files. When the app is done, the temporary files are gone.

Windows 7 Ultimate x64.

Friedrich

[NewsArchive]

Hi Friedrich,

thank you for your answer. I've done more tests. We have to distinct two
cases:

1.) files created by sb7.exe

2.) files created by generated setup.exe

In this post, I will discuss only 1.)

I've tested on different machines (W2008R2 and W7) with different
AV-products (Kaspersky and Bitdefender). On all machines I've tested, an
empty TMP-File is generated on sb7.exe STARTUP (see attached
screenshots). This file is created with the option "delete on close", so
there is NO PROBLEM with this file. I'm just interested, what this file
is good for.

Thanks for your answer.

Markus

[NewsArchive]

Hi Marcus,

There is not any source code in the SetupBuilder IDE itself that creates
this file. So I can't tell you what this file is good for ;-)

Friedrich

[NewsArchive]

Markus

My bet is that it is because of the way you are starting SB7 ( using a QuickLaunch
instead of a regular Shortcut) . see more details here...


http://msdn.microsoft.com/en-us/library/ff545765.aspx

It has to do with ZwCreateFile and because started from a QuickLaunch, the
fileDisposition was being set to Delete. see ..

=============
FileDispositionInformation


Usually, sets the DeleteFile member of a FILE_DISPOSITION_INFORMATION to TRUE, so the
file can be deleted when ZwClose is called to release the last open handle to the file
object. The caller must have opened the file with the DELETE flag set in the
DesiredAccess parameter.
=========
at link
http://msdn.microsoft.com/en-us/library/ff567096.aspx

Maybe this is causing what you are seeing.

JohnG
"System O/S requirements said Windows XP or better, so we used Linux"

[NewsArchive]

Very interesting information, John! Thanks for sharing!!

Friedrich

[NewsArchive]

Hi Friedrich,

Just for your information: I've digged a little more into this issue.
The ~DF...TMP-File is created by ole32.dll. This is caused by your call
to ole32.StgCreateDocfileOnILockBytes at adress sb7.0x4BDE3 (V7.6.3576).

Markus

[NewsArchive]

Hi Markus,

> Just for your information: I've digged a little more into this issue. The
> ~DF...TMP-File is created by ole32.dll. This is caused by your
> call to ole32.StgCreateDocfileOnILockBytes at adress sb7.0x4BDE3
> (V7.6.3576).

We do not call StgCreateDocfileOnILockBytes from the setup runtime!

Friedrich

[NewsArchive]

>
> We do not call StgCreateDocfileOnILockBytes from the setup runtime!
>

BTW, and we do not call it from the SB7 IDE. There is not any function call
to this API in any source code file.

Friedrich

[NewsArchive]

Hi Friedrich,

to my second problem: The temp file, that is left over, if I execute my
setup.exe:

The temp file is the SBKERNEL.LIB. It cannot be deleted, because it is
write protected in the temp folder. It is write protected, because I
hold my actual SetupBuilder program folder in SVN with the "needs-lock"
attribute. This causes all SB7 program files to be write protected and
your compile process, which includes the SBKERNEL.LIB in the resulting
setup.exe takes care about this write protection flag and restores it in
the temp folder when the setup.exe is executed. But your tmp cleanup
routine cannot delete write protected files and for that, it is left over...

My workaround:

I will add the script line

Set File Attributes for "%TMPDIR%\*.*"

at the end of every script.

Markus

[NewsArchive]

Friedrich,

from the sb7.exe

Markus

[NewsArchive]

Markus,

>
> from the sb7.exe
>

We do not call it from the sb7.exe IDE. There is not any function call to
this API from any source code file.

Friedrich

[NewsArchive]

Ok, but to close this thread:

please see attached screenshot.

if you open sb7.exe via double click from the explorer on a FRESH
INSTALLED W2008R2 with NO AV-PRODUCTS and NO OTHER SOFTWARE and look at

C:\Users\Administrator\AppData\Local\Temp\1

you see this file gets created if sb7.exe shows the "Get started screen"
and deleted, if you close sb7.exe.

The adresses in the screenshot differ, because it's an other sb7 version.

Further: If you look at the loaded sb7.exe in memory, you can see the
call at (baseimageaddress+0x04BDE3). And if you track this file creation
with sysinternals procmon, you see a full stack trace to this adress (ok
to 0x4bde8, because it's the return address).

If you still think, that the sb7.exe doesn't create this, file, jut
ignore this thread, because it's absolutely no problem. But if you want,
I can provide you with more detailed information via mail.

Markus

[NewsArchive]

Hi Markus,

We do not call the StgCreateDocfileOnILockBytes API from our source codes.
But the "Get Started Task" window embeds an Internet Explorer OLE container
control "Shell.Explorer.2". I see that, whenever the "Get Started Task"
window is opened, a temporary file is automatically created (OLE compound
storage file?). So perhaps embedding "Shell.Explorer.2" creates the
temporary file(s) behind the scenes. Unfortunately, it's completely out of
our control :-(

Friedrich

[NewsArchive]

Bingo.

Markus Zander