I am using the services module to implement a REST API. One resource allows POSTs with uploaded files. During a services pre-process function I save the file to the temp directory. During a services post-process function, I move the file to a private directory, call file_usage_add, and save the host entity. When a validation error occurs between saving the temp file and moving the temp file to a permanent location, I am not explicitly deleting the temp file. I thought drupal cron would take care of this for me, since no entry for this file exists in file_usage. However, it doesn't appear that cron is taking care of this for me. Any thoughts as to why this is?

When reviewing file_managed, I see the temporary file that I'd like deleted. When reviewing file_usage, I don't see any corresponding record.

Update -- One additional piece of info: in most cases, the file is actually missing. I believe this is due to OS reboot clearing out the /tmp directory. Regardless, would system_cron still remove the file_managed entry for a file if the actual file were no longer found?

This problem arose since I started uploading files from a native mobile app. The filename is the same every upload. There are some cases where the temp filename doesn't exist in the /tmp directory, but a record in file_managed still exists with a URI of that filename. So I'm getting an integrity error when the file_managed table is being saved. I plan on updating the app to create a random filename. In the meantime, I'd like to clean up the database and surrounding "glue" logic that manages these files. If system_cron will do it all for me then great. But from what I can tell, system_cron is not removing old, completely unused (and unreferenced) records in file_managed.


Drupal automatically deletes temporary files in system_cron().

Permament files which have no file_usage are not deleted, however.

  • That's what I thought. However, entries in file_managed are still hanging around, even though no corresponding entries exist in file_usage, and no actual file exists anymore. I must be missing something here... – lkiss80 Apr 3 '12 at 7:08
  • 3
    @lkiss80 The file won't be deleted unless it has a status of zero in the file_managed table – Clive Apr 3 '12 at 7:57
  • 4
    And additionally, must be older than 6 hours. – Berdir Apr 3 '12 at 8:03
  • @Clive - Thanks. Your response prompted me to double checked the status bit. I originally referenced a book that incorrectly flipped the meaning of this bit. Thanks again! – lkiss80 Apr 3 '12 at 8:27

Your Answer

