Daily /tmp/olduntouched-* are created

At a daily basis, Security Ninja creates a file named /tmp/olduntouched-* with an individual suffix, each ~0.8 MiB in size. Since /tmp is usually a tmpfs, if it remains unrecognised, it can lead to OOM kills and system crashes after time.

This is done by the daily vulnerability list update. I checked the code and found this diff to fix it, and generally make sense, but I’m not 100% sure:

        $tmp_download_file = download_url( $request_url );
        
        if ( !is_wp_error( $tmp_download_file ) ) {
            WP_Filesystem();
            global  $wp_filesystem ;
            $upload_dir = wp_upload_dir();
            $secninja_upload_dir = $upload_dir['basedir'] . '/security-ninja/';
            $outdated_foldername = $secninja_upload_dir . 'outdated/';
            $outdated_file = $outdated_foldername . 'outdated.dat';
            
            if ( !is_dir( $outdated_foldername ) ) {
                // recursive folder creation
                wp_mkdir_p( $outdated_foldername );
-               $wp_filesystem->move( $tmp_download_file, $outdated_file, true );
-               $wp_filesystem->delete( $tmp_download_file );
            }
+           $wp_filesystem->move( $tmp_download_file, $outdated_file, true );
        } else {
+           $wp_filesystem->delete( $tmp_download_file );
        }

Currently, it looks like the “outdated” list is downloaded and moved into place only once. Afterwards, since the “outdated_foldername” does already exist, new lists are downloaded every day but nothing done with them. With the above change, the newly downloaded list is always moved into the “outdated_foldername” (which worked well on today’s schedule), and if the download failed, the potentially existing incomplete file is deleted. The latter might require and additional existence check, to avoid errors if no file has been created at all by the download attempt.