Problematic temporary BAT files

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Problematic temporary BAT files

Eli Zaretskii
> Date: Wed, 15 Oct 2014 19:45:23 +0200
> From: Bostjan Mihoric <[hidden email]>
>
> 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
> following options:
> 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.

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Problematic temporary BAT files

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
> From: Bostjan Mihoric <[hidden email]>
>
> On Wed, Oct 15, 2014 at 10:56 PM, Eli Zaretskii <[hidden email]> wrote:
>
>     > Date: Wed, 15 Oct 2014 19:45:23 +0200
>     > From: Bostjan Mihoric <[hidden email]>
>     >
>     > 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
>     > following options:
>     > 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.
>    
>
> 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

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Problematic temporary BAT files

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.


On Thu, Oct 16, 2014 at 5:22 PM, Eli Zaretskii <[hidden email]> wrote:
[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
> From: Bostjan Mihoric <[hidden email]>
>
> On Wed, Oct 15, 2014 at 10:56 PM, Eli Zaretskii <[hidden email]> wrote:
>
>     > Date: Wed, 15 Oct 2014 19:45:23 +0200
>     > From: Bostjan Mihoric <[hidden email]>
>     >
>     > 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
>     > following options:
>     > 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.
>
>
> 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


_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Problematic temporary BAT files

Eli Zaretskii
> Date: Fri, 17 Oct 2014 15:14:37 +0200
> From: Bostjan Mihoric <[hidden email]>
>
> 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?

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Problematic temporary BAT files

Bostjan Mihoric

On Fri, Oct 17, 2014 at 3:27 PM, Eli Zaretskii <[hidden email]> wrote:
> Date: Fri, 17 Oct 2014 15:14:37 +0200
> From: Bostjan Mihoric <[hidden email]>
>
> 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

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Problematic temporary BAT files

Eli Zaretskii
> Date: Sat, 18 Oct 2014 00:48:07 +0200
> From: Bostjan Mihoric <[hidden email]>
>
>     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.

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32