Problematic temporary BAT files

[Bostjan Mihoric]

Hello,

I have noticed that Make 4.0+ works a bit differently than Make 3.80.
When encountering command prompt (cmd.exe) built-in commands (such as
"del") or redirection,
it will generate a batch (BAT) file in the temporary folder and execute it.
While I see what is being achieved here, there are problems with these
batch files.

Even if we ignore the impact this can have on (SSD) drive wear (doing a lot
of big compilations),
there are Windows systems out there where the policies deny running
programs from
temporary folders (which are one of the first stops for malware).

I thought of simply using Make 3.80, but parallel compilation has become
very tempting now that
Make supports syncing the outputs (as of 4.0).

What I would very much appreciate is if there would be at least one of the
following options:
A) Option to not generate BAT files (work like Make 3.80 in this regard).
B) Option to set the target directory for temporary BAT files (instead of
using system defaults).

Could you please direct me, where should I submit this suggestion so that
it has a chance of being implemented?

Thank you very much.

With kind regards,
Bostjan

[Eli Zaretskii]

Date: Wed, 15 Oct 2014 19:45:23 +0200
Even if we ignore the impact this can have on (SSD) drive wear (doing a lot of
big compilations),

I don't think this is a real problem. There are systems out there
which have the page file on an SSD disk, and still the disk resources
are enough to go on long after the machine is upgraded and abandoned.

there are Windows systems out there where the policies deny running
programs from temporary folders (which are one of the first stops
for malware).

You can control where the batch files are created, see below.

What I would very much appreciate is if there would be at least one of the
A) Option to not generate BAT files (work like Make 3.80 in this regard).

Not going to happen, unless someone submits a clean patch to do that,
and shows that the problems that caused us to switch to batch files
are not reintroduced back.

B) Option to set the target directory for temporary BAT files (instead of using
system defaults).

The "system defaults" are documented here:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx

This is the function used by Make on Windows to obtain the temporary
directory name. By setting one of the environment variables
documented on that page, you can control where Make creates these
batch files.

Could you please direct me, where should I submit this suggestion so that it
has a chance of being implemented?

Here.

[Eli Zaretskii]

[Please keep the list address on the CC, so that it gets archived, and
seen by others.]

Resending to the list.

Date: Thu, 16 Oct 2014 17:06:01 +0200

Date: Wed, 15 Oct 2014 19:45:23 +0200
Even if we ignore the impact this can have on (SSD) drive wear (doing a

lot of

big compilations),

I don't think this is a real problem. There are systems out there
which have the page file on an SSD disk, and still the disk resources
are enough to go on long after the machine is upgraded and abandoned.
True, such systems are around. Yet, I observed a lot of BAT files being
created.
If I'm not mistaken, one gets generated for every command (every line that fits
the
rule). And every one can mean write amplification of 512 KiB (or whatever SSD
write block is sized at), even if BAT file is 100 B. I would not underestimate
this.
But let's skip this for now, as it is of less importance. This part could
indeed be
solved by redirecting the temporary folders as you suggest.

there are Windows systems out there where the policies deny running
programs from temporary folders (which are one of the first stops
for malware).

You can control where the batch files are created, see below.

What I would very much appreciate is if there would be at least one of

the

A) Option to not generate BAT files (work like Make 3.80 in this regard).

Not going to happen, unless someone submits a clean patch to do that,
and shows that the problems that caused us to switch to batch files
are not reintroduced back.

B) Option to set the target directory for temporary BAT files (instead of

using

system defaults).

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx
This is the function used by Make on Windows to obtain the temporary
directory name. By setting one of the environment variables
documented on that page, you can control where Make creates these
batch files.
Yes, I already knew this is possible, but... Please assume that temporary
folders are
blocked from execution (for a good reason). This goes no matter where I
redirect them.
Malware also looks up that same API, so the target folder should be blocked.
I hope you understand.

Could you please direct me, where should I submit this suggestion so that

it

has a chance of being implemented?

Here.
Thanks!
Bostjan

[Bostjan Mihoric]

Ooops, sorry about that.
Was not paying attention to what gmail removed.

Anyway, that's the problem. Redirecting the temporary folder doesn't work
in this case.

Thanks.

Post by Eli Zaretskii
[Please keep the list address on the CC, so that it gets archived, and
seen by others.]
Resending to the list.

Date: Thu, 16 Oct 2014 17:06:01 +0200

Date: Wed, 15 Oct 2014 19:45:23 +0200
Even if we ignore the impact this can have on (SSD) drive wear

(doing a

lot of

big compilations),

I don't think this is a real problem. There are systems out there
which have the page file on an SSD disk, and still the disk resources
are enough to go on long after the machine is upgraded and abandoned.
True, such systems are around. Yet, I observed a lot of BAT files being
created.
If I'm not mistaken, one gets generated for every command (every line

that fits

the
rule). And every one can mean write amplification of 512 KiB (or

whatever SSD

write block is sized at), even if BAT file is 100 B. I would not

underestimate

this.
But let's skip this for now, as it is of less importance. This part could
indeed be
solved by redirecting the temporary folders as you suggest.

there are Windows systems out there where the policies deny running
programs from temporary folders (which are one of the first stops
for malware).

You can control where the batch files are created, see below.

What I would very much appreciate is if there would be at least

one of

the

A) Option to not generate BAT files (work like Make 3.80 in this

regard).

Not going to happen, unless someone submits a clean patch to do that,
and shows that the problems that caused us to switch to batch files
are not reintroduced back.

B) Option to set the target directory for temporary BAT files

(instead of

using

system defaults).

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx

This is the function used by Make on Windows to obtain the temporary
directory name. By setting one of the environment variables
documented on that page, you can control where Make creates these
batch files.
Yes, I already knew this is possible, but... Please assume that temporary
folders are
blocked from execution (for a good reason). This goes no matter where I
redirect them.
Malware also looks up that same API, so the target folder should be

blocked.

I hope you understand.

Could you please direct me, where should I submit this suggestion

so that

it

has a chance of being implemented?

Here.
Thanks!
Bostjan

[Eli Zaretskii]

Date: Fri, 17 Oct 2014 15:14:37 +0200
Redirecting the temporary folder doesn't work in this case.

Sorry, I'm probably missing something here. What exactly is a
definition of a "temporary folder" for this purpose? IOW, in which
folders are you not allowed to invoke programs or batch files?

I thought the problem was with the temporary folder under
CSIDL_PROFILE. The TEMP environment variable is set to it as a side
effect. But you seem to be saying that no matter which folder TEMP
points at, that folder would be regarded as a "temporary folder", is
that right? How can this make sense, if TEMP can be set differently
in every console cmd session a user has?

[Bostjan Mihoric]

Post by Eli Zaretskii

Date: Fri, 17 Oct 2014 15:14:37 +0200
Redirecting the temporary folder doesn't work in this case.

Sorry, I'm probably missing something here. What exactly is a
definition of a "temporary folder" for this purpose? IOW, in which
folders are you not allowed to invoke programs or batch files?
I thought the problem was with the temporary folder under
CSIDL_PROFILE. The TEMP environment variable is set to it as a side
effect. But you seem to be saying that no matter which folder TEMP
points at, that folder would be regarded as a "temporary folder", is
that right? How can this make sense, if TEMP can be set differently
in every console cmd session a user has?

Ah, I see. Up until now, I knew that I could override temporary folder for
the console session. But I thought that any new program that gets launched,
will have the system value restored (including Make, of course). The test I
just performed shows otherwise (child process inherits the value). This
means I can probably use this localized redirection of temporary folder.

Thank you for your help!

Bostjan

[Eli Zaretskii]

Date: Sat, 18 Oct 2014 00:48:07 +0200
I thought the problem was with the temporary folder under
CSIDL_PROFILE. The TEMP environment variable is set to it as a side
effect. But you seem to be saying that no matter which folder TEMP
points at, that folder would be regarded as a "temporary folder", is
that right? How can this make sense, if TEMP can be set differently
in every console cmd session a user has?
Ah, I see. Up until now, I knew that I could override temporary folder for the
console session. But I thought that any new program that gets launched, will
have the system value restored (including Make, of course).

This is only so for programs invoked from a desktop shortcut, or from
the Start->Run dialog, or by double clicking in Explorer. For those,
the parent process is the Windows Explorer, so those programs get the
system-wide values of these variables.

But for a program invoked from the cmd window, the parent process is
cmd.exe, so it gets environment variables set in that cmd window.

The test I just performed shows otherwise (child process inherits
the value). This means I can probably use this localized redirection
of temporary folder.
Thank you for your help!

You are welcome.