Temp Files not removed (chk_all)

[celtic-coder]

Hi Thomas (@ThomasMertes),

After running the Windows command s7 chk_all, the following files are left behind in the C:\seed7\prg folder:

• tmp_s7c.c
• tmp_s7c.o
• tmp1_chkflt.c
• tmp_chkflt.c
• tmp_chkflt.o
• tmp1_chkenum.c
• tmp_chkenum.c
• tmp_chkenum.o
• tmp1_chkbitdata.c
• tmp_chkbitdata.c
• tmp_chkbitdata.o

Is this expected? For the "checkCompiler" function a "removeFile" is used to remove the "tmp" temporary files. However, I may be reading the code incorrectly and assuming that these other "tmp" files should also be removed for checking the interpreter. In any case, I was wondering if other possible steps might have been inadvertently omitted.

Kind Regards, Liam

[ThomasMertes]

Hi Liam,

I don't think that you omitted some steps. If s7 chk_all writes

compiling the compiler - okay
chkint ........... okay
chkovf ........... okay
chkflt ........... okay
chkbin ........... okay
chkchr ........... okay
chkstr ........... okay
chkidx ........... okay
chkbst ........... okay
chkarr ........... okay
chkprc ........... okay
chkbig ........... okay
chkbool ........... okay
chkenum ........... okay
chkbitdata ........... okay
chkset ........... okay
chkhsh ........... okay
chkfil ........... okay
chkexc ........... okay

everything should be OK.

The program chk_all.sd7 is the regression test of Seed7. This program interprets and compiles individual test programs. Yes, in "checkCompiler" the function "removeFile" is used to remove the "tmp" temporary files. But in case a compilation test fails the temporary files are left untouched. Sometimes they are renamed from tmp_... to tmp1_... in order do preserve an existing tmp_... file as tmp1_.... If s7 chk_all did not write any error messages there should be no temporary files.

Files like tmp_xxx.c, tmp_xxx.cerrs, etc. are generated by the Seed7 compiler. If the compilation succeeds they are removed afterwards (except if the debugging option -g is used). If the compilation with the C compiler fails you get some error message and the temporary files are left intact to allow the investigation of the cause.

I have to admit that I do not follow how many tmp_... are in my prg directory and if some of them should not be there. Btw.: These files are not in a /tmp directory because with some C compilers this caused problems.

There is a quirk of Windows that could play a role here. In windows you cannot remove a file that is currently in use by some other process (Linux+Unix+BSD have no problem with that). In chk_all.sd7 and in s7c.sd7 processes are started and afterwards a file created by this process is removed. I have seen incidents where the remove failed although the process had been terminated (maybe some antivirus software keeps the file open after the normal process has terminated). In src/chkccomp.c I consider this quirk of Windows by trying to remove a file in a loop until the remove succeeds (or 20 seconds have elapsed). The function "removeFile" has no special code to consider this Windows quirk.

[celtic-coder]

Hi Thomas (@ThomasMertes),

I re-ran the "chk_all" again today and the command window output from "compiling the compiler" down to the final "chkexc" check was identical to your earlier listing. So, that part worked correctly. There were some new files left behind, but as it turned out, it was mostly the same as the last time. As you said, it probably has something to do with file locking in Windows preventing the files from getting deleted properly.

As expected, the "s7c.exe" compiler binary was re-created. But its content was modified in comparison to the previously existing version. Would this have been expected? The content of the following files remained the same, but their "Date Modified" timestamps were updated to today's date/time:

• chkflt.exe
• chkbitdata.exe
• chkfil.exe
• chkexc.exe

In any case, I will close this issue as it was more an FYI if something might have been amiss in the "chk_all" checking process.

Kind Regards, Liam