How to fix madExcept creating temporal files in User\LocalSettings\Temp

Question

I sterated using "Standard User Analyzer" from Application Compatibility toolkit and it reported that my app is not UAC compatible because:

"DeleteFileA: File (\Device\HarddiskVolume1\Documents and Settings\Administrator\Local Settings\Temp\mtgstudio.madExcept) is denied 'DELETE' access with error 0x5."

"DeleteFileA: File (\Device\HarddiskVolume1\Documents and Settings\Administrator\Local Settings\Temp) is denied 'DELETE' access with error 0x5."

Checking the madExcept.pas file I found:

function GetTempPath : AnsiString;
var arrCh : array [0..MAX_PATH] of AnsiChar;
begin
  if windows.GetTempPathA(MAX_PATH, arrCh) > 0 then begin
    result := arrCh;
    if result <> '' then begin
      CreateDirectoryA(PAnsiChar(result), nil);
      if result[Length(result)] <> '\' then
        result := result + '\';
      result := result + KillExt(ExtractFileName(ModuleName(0))) + '.madExcept';
      CreateDirectoryA(PAnsiChar(result), nil);
      result := result + '\';
    end;
  end else
    result := '';
end;

Is there a good way to overwrite the madExcept behaviour and store the temp files in a UAC allowed location?

madExcept appears to be doing nothing wrong here. Why should it not write to the temporary directory? I don't understand why your user's temp directory is `Documents and Settings\Administrator\Local Settings\Temp`. Are you really running as administrator? — David Heffernan, Sep 21 '11 at 13:45
I agree with David. This looks like the proper directory to be writing this sort of thing. If not here, then where would temp files go? — Chris Thornton, Sep 21 '11 at 13:54
Your computer's permissions are broken, fix your machine, not madexcept. UAC does NOT block Temp folder by default. — Warren P, Sep 21 '11 at 14:33
I wonder if madexcept authors knows about `IncludeTrailingPathDelimiter` and `ChangeFileExt`... (I was under impression what they dont publish their source and never reviewed their code.) — Premature Optimization, Sep 21 '11 at 17:04
@downvoter the code runs on very old delphi versions so no path delim method. MadExcept also needs not to depend on much RTL just like a memory manager. ChangeFileExt not appropriate here. memory manager. ChangeFileExt not appropriate here. — David Heffernan, Sep 22 '11 at 00:21
@David Heffernan, you are misinforming us, string building is working with `AnsiString`, and thus invoking RTL memory manager for at least one allocation (and up to 4 in case of badly fragmented heap). Also, this code *calls* `ExtractFileName`, so `SysUtils` is in dependency list already and calling `ChangeFileExt` (which *appropriately* replaces clumsy expression on line 10) would do no harm. Granted, `IncludeTrailingBackslash` helper has been introduced only in D5, however it is not clean to reproduce its behaviour in such manner. — Premature Optimization, Sep 22 '11 at 02:20
@downvoter SysUtils is used, but I bet not much else. Please share the equivalent code using ChangeFileExt? All I can see is filename+newext. — David Heffernan, Sep 22 '11 at 02:30
@David Heffernan, "not much else" as in "almost false"? **:-)** Equivalent (i have no their source, so - speculating): `LowerCaseResult + ChangeFileExt(ParamStr(0), '.hardcoded')`. I guess you have source of the library you are defending, so please look there for exact meaning of `ModuleName` and `KillExt`. Seriously, despite of being so popular, this code cries for refactoring. — Premature Optimization, Sep 22 '11 at 10:20

score 10 · Accepted Answer · answered Sep 21 '11 at 13:54

It doesn't look like there's anything to fix. The GetTempPath API function is exactly the function to use to get a location where a program is allowed to create temporary files. That the compatibility tester was unable to delete the directories doesn't mean that the directories should have been someplace else. It only means they couldn't be deleted at the time the program tried. It could be that another program (such as the one being tested) had a file open in one of those directories; Windows doesn't allow folders to be deleted when there are open files in them.

One possible source of problems is the way MadExcept creates the directories. It creates them such that they inherit the permissions of their parent directories. If deletion is forbidden for the parent directory, then it will also be forbidden for the newly created temp directories. That partly points to a configuration problem on your system: GetTempPath might be returning a path for a directory that doesn't exist. It just returns the first value it finds in any of the TMP, TEMP, and USERPROFILE environment variables. It's the user's responsibility (not your program's) to make sure those are accurate.

Knowing that MadExcept uses GetTempPath to discover the temp directory gives you an opportunity. You can call SetEnvironmentVariable to change the TMP value for your process, and MadExcept will create its directory there instead. (But if the system-designated location for temporary files already doesn't work, good luck finding some alternative to use.)

How to fix madExcept creating temporal files in User\LocalSettings\Temp

1 Answers1