How come compiling .exe fails to....

[SFSxOI]

Just noticed this with PB 5.10. If I compile some code to a .exe and then make changes to the code and compile again using the same .exe name (e.g. someapp.exe) into the same folder where the first compile .exe exists with the same name I do not get a warning or message asking if I want to replace the file. Instead, compile finishes as expected with no issues/warnings but when I look at the time stamp of the .exe (which should have been over written by the new compile) the time stamp has not changed. This means I can't simply look at the newer compiled .exe and determine if its newer so I don't know if the newer .exe actually compiled or not.

[skywalk]

It has been this way since at least v4.5.
I've gotten used to it and now prefer one less prompt.
If my exe/dll is approved, I move it out of the development folder so it cannot be overwritten.

[SFSxOI]

It has? Guess I never noticed it before because I usually compile each compile into its own seperate 'generations' folder.

[PMV]

If the compiler posts no errors, it should be ok.
If you prefer to have the timestamp updated,
post it as a feature request.

I have never looked at the timestamp of the exe.

[SFSxOI]

I look at time stamps all the time. Its just part of my work to do so and has become second nature. Ya gotta look at every little thing when you do malware and botnet analysis for a living. However, what bought it to my attention this time was that I was doing a quick value change on a constant in some code for a small utility that had not been deployed yet for Windows 8. So this time I just opened up the source code, did the 10 second change, and compiled it in the same folder where the original .exe existed instead of creating a new folder for it. I looked at the time stamp of the file to get the log entry info I needed and thats when I realized the time stamp had not changed.

[IdeasVacuum]

...Just add a tool to the IDE that deletes the existing exe before the compiler writes a new one.

[fsw]

... compile finishes as expected with no issues/warnings but when I look at the time stamp of the .exe (which should have been over written by the new compile) the time stamp has not changed. This means I can't simply look at the newer compiled .exe and determine if its newer so I don't know if the newer .exe actually compiled or not.

The same happens on OSX...

[MachineCode]

when I look at the time stamp of the .exe (which should have been over written by the new compile) the time stamp has not changed

It's normal Windows behavior. You have to look at the MODIFIED stamp, not CREATED stamp. The same behavior happens if you create a Notepad file in Windows over an existing one, or indeed any other file over an existing one. Not a PureBasic bug.

[luis]

and compile again using the same .exe name (e.g. someapp.exe) into the same folder ... when I look at the time stamp of the .exe (which should have been over written by the new compile) the time stamp has not changed.

Using 510 x86 win7, selecting compile -> create executable here the timestamp changes. The one you see normally looking at a file inside a folder using windows explorer. I suppose you are referring to that one, not the creation time.

[SFSxOI]

It's normal Windows behavior. You have to look at the MODIFIED stamp, not CREATED stamp. The same behavior happens if you create a Notepad file in Windows over an existing one, or indeed any other file over an existing one. Not a PureBasic bug.

Hmmm, no its not normal Windows behavior. If it were normal windows behavior there would be a message warning/asking about overwriting/replacing an existing file of the same name in the same location.

The same behavior does not take place with notepad. You can check it yourself; If a notepad .txt file is created and saved, then notepad is closed then reopened and another .txt file created and saved in the same location with the same name as the previously created existing .txt file there will be a warning about overwriting the file. This doesn't happen in this case with compiling a .exe to the same location with the same name as an existing previously compiled .exe, there is no message and there should be.

So if PureBasic effectively supresses or prevents this warning by not changing something to do with time stamps or by another method or by not allowing the message then its not being windows compliant or compatable because the compliant compatable thing is to show a message when a file is overwritten/replaced in a case like this. It is windows compliant/compatable to allow the warning/asking message about overwriting/replacing any recognized file extension type (e.g. .exe, .dll, .txt, etc...) file of the same name in the same location being used from any session of an application unless supressed for specific legitimate purposes by legitimate methods (for example, silent install software).

In some ways this Purebasic behavior, by there not being a warning/asking message about overwriting/replacing, is malware like behavior. Not saying Purebasic is malware because its not malware, just noting that the PureBasic behavior in this aspect is the same basic behavior that may be seen with some malware (like some of the recent Java related malware exploits).

But I suppose asking or requesting that expected behavior (the prompt asking/warning about overwriting/replacing the file) be placed in or restored to PureBasic is useless. Its not a feature request because because its not a feature thing, its an expected normal windows compliant/compatable thing and asking that PureBasic be windows compliant/compatable in this respect is useless. Its not a bug because (maybe obviously) its by design (if it is by design, although not compliant/compatable for Windows). So there is nothing to request, however, this behavior should be noted in the help and any other documentation for PureBasic.

[MachineCode]

Sorry, I was talking about the timestamps after the same file was overwritten or re-created after confirmation. They do remain the same for file creation.

But, yes, the IDE could (make it optional!) ask the user if they want to overwrite the existing exe.

And now:

the time stamp has not changed. This means I can't simply look at the newer compiled .exe and determine if its newer so I don't know if the newer .exe actually compiled or not.

Yes you can: just look at the MODIFIED timestamp, as I said. It changes with every fresh exe creation, which was the point of my original reply.