File-based caching for Drupal 4.6

I think there is a problem with the setcookie() usage in session.inc. As used currently, the cookie for drupal_uid doesn't specify a path, which means that the cookie (at least in my test -- Firefox on Mac running Drupal 4.6.6 on Mac Apache / PHP 5) gets set for each system path.

See the attached.

I "fixed" this by changing the cookie function to mirror Drupal's sesion timeout limit and setting the path to "/":

- setcookie('drupal_uid', $user->uid);

+ $cookie_domain = ""; // the domain for the cookie
+ $cookie_time = time()+(60*60*24*30); // the cookie expiration time is today + 30 days
+ setcookie('drupal_uid', $user->uid, $cookie_time, "/", $cookie_domain);

If this behavior is "by design" let me know.

I had a further problem.

When logging in, the drupal_uid cookie was always being set to 0.

I moved a copy of the cookie setting function (above) into user.module function user_login() and the problem corrected:

// Update the user table timestamp noting user has logged in.
db_query("UPDATE {users} SET changed = '%d' WHERE uid = '%s'", time(), $user->uid);
//
// If the file_cache and file_cache_fastpath are both enabled, this cookie
// will be used to determine whether or not a user is logged in without
// actually loading all the session information from the database.
$cookie_domain = ""; // the domain for the cookie
$cookie_time = time()+(60*60*24*30); // the cookie expiration time is today + 30 days
setcookie('drupal_uid', $user->uid, $cookie_time, '/', $cookie_domain);

I could not get this to work on windows because a fatal error in using unlink(). Luckily I had a guy that knows more PHP around. This is what I got back from him.

//line 381

if (flock($fp, LOCK_EX)) {
      	// added fclose so that windows can delete the file
      	fclose($fp);
        unlink($file);
      }


function cache_filename($cid) {
  global $file_cache;
  // added filename ending to make windows respond faster to large caches of files.
  // TODO:need path backslash fix by checking for windows
  return $file_cache .'\\'. md5($cid).'.cache';
}

I had to add the following code to the DEVEL module during site testing, otherwise I couldn't clear my menu cache:

/**
 * Menu callback; clears all caches, then redirects to the previous page.
 */
function devel_cache_clear() {
  db_query('DELETE FROM {cache}');
  //erase filecache patch files
  if (function_exists('cache_clear_all')) {
    cache_clear_all();
  }  
  drupal_set_message('cache cleared').
  header('Location: '. referer_uri());
  exit();
}

That DEVEL patch did not seem to do the trick. I tried using system_exit() and system_cron() to unlink all files in the $file_cache directory on demand, but neither works.

I think we need a function that allows manual emptying of the filesystem cache, or am I missing an existing feature?

The following does what I think I need, but may be overkill:

/**
 * Menu callback; clears all caches, then redirects to the previous page.
 */
function devel_cache_clear() {
  db_query('DELETE FROM {cache}');
  //erase filecache patch files
  if (function_exists('cache_clear_all')) {
    global $file_cache;
    // if using file-based caching, perform routine garbage collection
    if ($file_cache && is_dir($file_cache)) {
      // delete all files older than the last call to cache_flush_all()
      $files = file_scan_directory($file_cache, '.', array('.', '..', 'CVS'));
      foreach ($files as $file) {
        if ($fp = fopen($file->filename, 'r')) {
          // We need an exclusive lock, but don't block if we can't get it as
          // we can simply try again next time cron is run.
          if (flock($fp, LOCK_EX|LOCK_NB)) {
            unlink($file->filename);
          }
        }
      }
    }
  }  
  drupal_set_message('cache cleared').
  header('Location: '. referer_uri());
  exit();
}

This allows for a manual flush of the filecache by the devel module.

As stated by the author will not be applied to 4.6, but stays here for whoever want to use it.