bugGNU Octave - Bugs: bug #67299, mkoctfile does not delete...

 
 

bug #67299: mkoctfile does not delete temporary object file (Windows)

Submitter:  Roland <roland67>
Submitted:  Wed 09 Jul 2025 04:37:35 PM UTC
   
 
Category:  Other Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 10.2.0 Release: 
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 11 Jul 2025 08:51:35 AM UTC, comment #10: 


> for i = 1:50
>   [~, s] = mkoctfile ('-s', 'setup_delays_oct.cc');
> endfor


Did the same from the Octave *GUI* on my Windows machine, got 39 temporary files in the working folder not deleted (plus 50 "oct-st******.o" files in the systems temp folder we are accepting). Screenshot showing only a part of them attached.

Repeated from the Octave *CLI* -> no such temporary file(s) left in folder!
I also checked the tempdir folder. The files are not shown there as well.

So yes, we can conclude
- it is an issue at least on Windows and it looks like coming from the strip executable. So far no one tested on MacOS.
- still strange there is a different behaviour running from the GUI or CLI.

Remark: The intermediate cc******.s assembler files are automatically deleted from the tempdir folder, showing up there for a short time only. So why not automatically delete the .o files? But this should not be our focus in this issue.


Roland <roland67>
Fri 11 Jul 2025 07:13:47 AM UTC, comment #9: 

As test code, I'm using


for i = 1:50
  [~, s] = mkoctfile ('-s', 'setup_delays_oct.cc');
endfor


On Linux, I get no extra files.

Rik <rik5>
Group administrator
Fri 11 Jul 2025 07:03:58 AM UTC, comment #8: 

The system temporary directory is made available by the OS to programs who are free to use it for any purpose.  Octave, and other programs, are not responsible for cleaning up their usage of it as that is deemed a responsibility of the operating system.

On Linux, normally a cron job will periodically clean the TMPDIR.  Alternatively, it also usually gets cleared by an initialization script on a reboot.  Some sysadmins mount TMPDIR in RAM for very fast RW access in which case it definitely disappears when the machine is rebooted.  Windows can choose not to clean this directory and leave it to the user.

But, for this bug report the important thing is the files in the current directory where compilation is happening.

The relevant code is in src/mkoctfile.cc and is quoted below.


      int status = run_command (cmd, verbose, printonly);

      clean_up_tmp_files (tmp_files);

      if (status)
        return status;
    }

  if (strip)
    {
      std::string cmd = "strip " + quote_path (octfile);

      int status = run_command (cmd, verbose, printonly);

      if (status)
        return status;
    }


Interestingly, there is an additional step after compilation when the "-s" strip option is used.  This is probably relevant.  After creation of the compiled file the "strip" executable is called.  Perhaps there is something wrong with that utility that is shipped with the Windows distribution of Octave.


Rik <rik5>
Group administrator
Thu 10 Jul 2025 04:01:14 PM UTC, comment #7: 

(1) Also confirming that windows likes to leave temp contents untouched until the user requests otherwise. they have a history of bad press from things being deleted automatically that shouldn't have been, so IMHO I'm okay with that.

(2) More on topic, since it's possible for the octave temp location to be set arbitrarily (e.g., I set tmpdir to c:\octave\temp in my .octaverc since my managed windows machine has certain user profile permissions restrictions), and I assume that's the location mkoctfile uses from within Octave (from the shell it should use the system default temp location, yes?), then it probably shouldn't be assumed that the OS will housekeep folders it may not know about. I have also noticed (on windows) my temp folder is rarely left empty, and not always crash related (which would be understandable). but assuming this can one can be pinned down within mkoctfile that could maybe be a separate discourse discussion to identify other culprits.

Nicholas Jankowski <nrjank>
Group Member
Thu 10 Jul 2025 03:42:00 PM UTC, comment #6: 

@Rik - just to be clear is it not happening on linux or is it just being cleaned up by the OS?

Nicholas Jankowski <nrjank>
Group Member
Thu 10 Jul 2025 09:35:58 AM UTC, comment #5: 

Thanks for the additional information.  I work only on Linux so one of the other developers will need to check the Windows-specific code here.

On Linux, files in the /tmp directory are periodically removed, often whenever the machine is rebooted.

It shouldn't be a problem on Windows given that the OS will probably give you a warning about running out of disk space and then you can manually clean up the hard drive.

Rik <rik5>
Group administrator
Thu 10 Jul 2025 09:23:22 AM UTC, comment #4: 

I'm still on Windows 10 Home, build 19045.5965.

To my experience Windows does not delete files in the tempdir folder by default. Checked right now and found files back to 2020 there. You have to run a cleanup manually from the "drive properties" dialog and explicitly enable "temporary files" in the list of items to clear (not selected by default) to get them removed.

Roland <roland67>
Thu 10 Jul 2025 07:27:57 AM UTC, comment #3: 

Thanks.  This shouldn't be happening so it would be good to fix it.  I know this doesn't happen on Linux, so this is likely to be due to differences between operating systems.  What version of Windows are you using?

The extra files in tempdir() are expected.  That shouldn't be any problem because your OS should clear that directory from time to time.

Rik <rik5>
Group administrator
Thu 10 Jul 2025 06:45:48 AM UTC, comment #2: 

1) I'm usually running mkoctfile from with Octave GUI, typically from within an m-file recompiling all functions in the project.

2) The files are left in the current folder next to the oct file if you sort by date.

*More notes*

I now tried runnig mkoctfile from the Octave CLI and did not find such files left after compiling several cc files - at least in the working folder.

Strange thing: With Octave CLI still open after compiling several files on the CLI opening Octave GUI and compiling from there I got no such temporary file for more than 20 compiles. After closing CLI and GUI, restarting GUI I get such temporary file about 1 out of 20 compiles now. Have not tried to restart the PC in between. I might test that later on.

But I found about 200 temporary files called e.g. "oct-p5gDVs.o" in %APPDATA%\local\temp which is Octave's tempdir() created within the last two days while testing this on my desktop PC. Will be many more on my notebook. According to creation time and file size these look like being the object files before linking/stripping (e.g. 1.5 MBytes while the respective stripped executable is about 20 kBytes). Each time I run mkoctfile one of these files are left. These files are not deleted independent of using -s or not. Also independent of running from within the GUI or CLI.

For me the issue is just annoying because I have to exclude them from getting into my GIT archive if I miss to delete them from the local folder. Not a functional problem.

But I'm happy to support with testing.

Roland <roland67>
Wed 09 Jul 2025 07:35:17 PM UTC, comment #1: 

1) Are you running mkoctfile from within Octave?  Or are you running it directly from a shell?

2) Is the temporary file in the current folder (where the compilation is happening) or is it in a temp directory?

Rik <rik5>
Group administrator
Wed 09 Jul 2025 04:37:35 PM UTC, original submission:  

When I compile .cc to .oct using mkoctfile I frequently see files named like "stZWKKZz" staying in the folder. It looks like this only happen if option -s (strip) is enabled.

Problem exist in all Octave versions I have tested so far: Octave 10.2.0, 10.2.1 in either mxe or w64.

Run "mkoctfile -s setup_delays_oct.cc" several times and watch the folder in Windows Explorer.

Note: This temporary file is exactly the size of the .oct generated independent of linking to any external library or not. So it might be some problem with copying / renaming files during the linking and stripping process.

Roland <roland67>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57393:  TempFiles.png added by roland67 (71KiB - image/png)
file #57386:  setup_delays_oct.cc added by roland67 (2KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by roland67 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-07-11 roland67 Attached File- Added TempFiles.png, #57393
    2025-07-10 rik5 StatusNeed Info Confirmed
        Summarymkoctfile does not delete temporary object file mkoctfile does not delete temporary object file (Windows)
    2025-07-09 rik5 StatusNone Need Info
    2025-07-09 roland67 Attached File- Added setup_delays_oct.cc, #57386

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code