Race condition

Why do you use mkdir() directly, instead of file_check_directory() in D6, and drupal_mkdir() or file_prepare_directory() in D7?

In the cleanup function in cron, why not simply check whether or not the name is the less_dir variable (which can be loaded after scanning the directory), deleting the rest?

A most annoying issue.

Your method looks solid, but is there any reason that you're using DirectoryIterator rather than file_scan_directory for D6?

I'm implementing this patch right now.

In response to #1347258-3: Race condition, the reason I use mkdir directly in D6 is that it allows for recursion folder creation, which is essential to finding a compiled file's original path.

I made a couple changes to your patch's changes:

/**
 * Helper function to create a new less dir.
 */
function _less_new_dir() {
  $less_dir = uniqid('', TRUE);
  $less_path = file_directory_path() .'/less/' . $less_dir;
  @mkdir($less_path, 0775, TRUE);
  variable_set('less_dir', $less_dir);
  return $less_dir;
}

/**
 * Implements hook_cron().
 */
function less_cron() {
  $less_dir = variable_get('less_dir', '');
  $found_files = file_scan_directory(file_directory_path() . '/less', '^.+$', array('.', '..', 'CVS', $less_dir), 0, FALSE);
  
  foreach ($found_files as $found_file) {
    _less_recursive_delete($found_file->filename);
  }
}

I thought the problem with the patch in #8 was that the name of the compressed css file changes with each "flush caches" so I developed another workaround (see attached patch). I think it is a bit simpler because it only renames the less directory before recursive deleting this.

The css filename still changes every time though, I think it is because of the serialize() call in drupal_get_css() which uses the creation date of the file or something. This name change is not good since this means the css file can not be cached very long in a browser.

This should be resolved in 7.x-2.5.