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.

1 Answer 1


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, 2012 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, 2012 at 7:57
  • 4
    And additionally, must be older than 6 hours.
    – Berdir
    Apr 3, 2012 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, 2012 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.