1. php creates a file named test.html and uses filectime to get the creation time t1

2. php deletes the file named test.html

3. php recreates the file named test.html and uses filectime to get the creation time t2

Why t1 = t2? ? Why is the creation time not updated? ? I used the clearstatcache function to clear the file status cache, but it didn't work. How to solve this problem? ? (Because when judging whether to regenerate the cache file, you need to know the creation time of the cache file, so it is very important..., please solve it~)
The following is the code for the problem that occurs in this situation (it is a bit dense, please be patient and read it) ):

<code>     // 頁面緩存
     if ((defined('DEBUG_MODE') && !DEBUG_MODE) && (defined('CACHE_CONTROL') && CACHE_CONTROL)) {
         $opr = $GLOBALS['module'] . '/' . $GLOBALS['platform'] . '/' . $GLOBALS['controller'] . '/' . $GLOBALS['act'];
         $cache_name = md5($opr) . TEMPLATE_SUFFIX;
         $cache_file = APP_DIR . '/' . $GLOBALS['module'] . '/' . $GLOBALS['platform'] . '/Cache/' . $cache_name;
         // 清除文件狀態(tài)緩存（就我使用的情況來看，壓根沒毛用...，這什么情況？？）
         clearstatcache();
         // 緩存文件不存在 創(chuàng)建
         if (!$GLOBALS['FOpr']->checkFile($cache_file)) {
            require_once $view_file;
            $GLOBALS['FOpr']->cFile($cache_file);
            $GLOBALS['FOpr']->wData($cache_file , ob_get_contents());
         } else {
            // 超時重新緩存
            if (time() > filectime($cache_file) + CACHE_LIFE_TIME) {
                require_once $view_file;
                // 緩存文件超時時，先刪除原緩存文件
                $GLOBALS['FOpr']->dFile($cache_file);
                // 新建同名緩存文件
                //（新建文件時，filectime 獲取文件創(chuàng)建時間一直沒更新！這個怎么破？？
                // 這導致我沒法重新生成緩存文件了?。?                $GLOBALS['FOpr']->cFile($cache_file); 
                // 寫入緩存
                $GLOBALS['FOpr']->wData($cache_file , ob_get_contents() , 'w');
            } else {
                // 加載緩存文件
                require_once $cache_file;
            }
         }
     } else {
         // 顯示動態(tài)文件（非緩存）
         require_once $view_file;
     }</code>

Reply content:

1. php creates a file named test.html and uses filectime to get the creation time t1

2. php deletes the file named test.html

3. php recreates the file named test.html and uses filectime to get the creation time t2

Why t1 = t2? ? Why is the creation time not updated? ? I used the clearstatcache function to clear the file status cache, but it didn't work. How to solve this problem? ? (Because when judging whether to regenerate the cache file, you need to know the creation time of the cache file, so it is very important..., please solve it~)
The following is the code for the problem that occurs in this situation (it is a bit dense, please be patient and read it) ):

<code>     // 頁面緩存
     if ((defined('DEBUG_MODE') && !DEBUG_MODE) && (defined('CACHE_CONTROL') && CACHE_CONTROL)) {
         $opr = $GLOBALS['module'] . '/' . $GLOBALS['platform'] . '/' . $GLOBALS['controller'] . '/' . $GLOBALS['act'];
         $cache_name = md5($opr) . TEMPLATE_SUFFIX;
         $cache_file = APP_DIR . '/' . $GLOBALS['module'] . '/' . $GLOBALS['platform'] . '/Cache/' . $cache_name;
         // 清除文件狀態(tài)緩存（就我使用的情況來看，壓根沒毛用...，這什么情況？？）
         clearstatcache();
         // 緩存文件不存在 創(chuàng)建
         if (!$GLOBALS['FOpr']->checkFile($cache_file)) {
            require_once $view_file;
            $GLOBALS['FOpr']->cFile($cache_file);
            $GLOBALS['FOpr']->wData($cache_file , ob_get_contents());
         } else {
            // 超時重新緩存
            if (time() > filectime($cache_file) + CACHE_LIFE_TIME) {
                require_once $view_file;
                // 緩存文件超時時，先刪除原緩存文件
                $GLOBALS['FOpr']->dFile($cache_file);
                // 新建同名緩存文件
                //（新建文件時，filectime 獲取文件創(chuàng)建時間一直沒更新！這個怎么破？？
                // 這導致我沒法重新生成緩存文件了?。?                $GLOBALS['FOpr']->cFile($cache_file); 
                // 寫入緩存
                $GLOBALS['FOpr']->wData($cache_file , ob_get_contents() , 'w');
            } else {
                // 加載緩存文件
                require_once $cache_file;
            }
         }
     } else {
         // 顯示動態(tài)文件（非緩存）
         require_once $view_file;
     }</code>

As far as your application scenario is concerned:

• filemtime can better complete the Cache timeout judgment logic;

• The file does not need to be deleted, because the filemtime will change after rewriting;

• There must be a reason why you deleted the file, but please see the "off-topic" under the answer

As far as deleting and creating files in PHP

The author did an experiment using the following code

<code>$path = __DIR__.'/test.txt';

file_put_contents($path, 'content1');
echo filectime($path),PHP_EOL;

unlink($path);
sleep(2);

file_put_contents($path, 'content2');
echo filectime($path),PHP_EOL;</code>

Result:

windows (windows 10 x64)

The return time is indeed the same. When I execute it for the second time, the time is still the same as the first time.
But I did see this txt disappear for 2 seconds and then be generated again. This may have such a logic under Windows (I haven’t gone into it yet). The picture below shows the file attributes I got after executing it for the second time:

CentOS under Linux

The return time will change

Off topic

In some file cache engines I wrote or I saw, the read cache operation did not delete the Cache file even if a timeout was detected.

• I’m not being lazy here, after all it’s easy to unlink

• Instead, it reduces necessary i/o requests and the risk of unlink caused by concurrency (Think about why?)

• Besides, according to inertial thinking, since you are accessing this cache, this cache will definitely be overwritten, so there is not much meaning in rebuilding after deletion

• The only problem is disk space occupation. For example, some caches that have not been accessed for a long time still occupy space. For this situation, we generally choose to tolerate it, or implement the code ourselves and use scheduled tasks to delete it

• smarty compiled files are similar to your scenario, his approach is: don’t delete