1

I have a use case (in D8) where file and corresponding directory needs to be deleted from the file system. The standard mechanism suggested by Drupal is to mark file as temporary and let cron take care of deletion. This means, in my case, that I need to keep track of the file deletion and only then delete the corresponding directory, if it empty. This can be easily avoided by simply using file_delete().

Why is this method not recommended?

The standard cron based deferred deletion causes other side effects with file replacement, etc.

Improve this question
4
  • Is there any reason to delete the directory (e.g. it will be created again from a different process, which fails if the directory exists already)?
    – avpaderno ♦
    Commented Apr 8, 2017 at 6:25
  • Yes, due to our storage scheme the directory will never be used again, so leaving it there just clutters the file system.
    – amit
    Commented Apr 8, 2017 at 13:11
  • This is difficult to do in Drupal 8. Replacing a file inline - particularly if you're using the core file upload field, will rename instead of replace. I've tried a few methods of doing this another way and nothing has worked so far that doesn't clash with the way Drupal tracks files.
    – Kevin
    Commented Apr 9, 2017 at 0:16
  • The file api is not in good state, I am curious to know why is file_delete() method not recommended? I suspect that this is used by cron anyways.
    – amit
    Commented Apr 10, 2017 at 17:14

1 Answer 1

Reset to default
1

Why is this method not recommended?

The function comments do give a nod to the reason:

Instead of directly deleting a file, it is strongly recommended to delete file usages instead. That will automatically mark the file as temporary and remove it during cleanup.

But perhaps the "file usage" part of that could have been expanded upon, if you're not aware there's proper reference tracking going on it could be confusing...

Put simply, multiple entities/things can reference a single file. Those references are stored as file usage records, which are consulted when the system wants to know if it's safe to delete a file. If a record exists, for the target file, it can't be deleted without breaking a link, so the system doesn't do it.

Rather than go through that process of checking usage then deleting every time a file is dereferenced, the system batches it up on a cron job for convenience.

If it's not convenient for your use case, and you are comfortable that the file delete is 'safe' with the above in mind, then you can happily ignore the recommendation and use file_delete directly.

If you do, make sure you clear up the file usage records at the same time, or you might end up with inconsistent data some time down the line.

Improve this answer
2
  • Marking this as accepted answer, please edit and mention that file_delete() does infact updates file usage, so in cases where file is being used once. file_delete can do both tasks.
    – amit
    Commented Apr 11, 2017 at 17:59
  • file delete may clear out the file_usage table for a file, but it doesn't delete the references. So for example, if you have a file field on an node, it will leave it as a hanging reference. If you open up that node and it fails to load the file, it will show that file field as empty, and upon saving it, it will remove the file reference to the previously deleted file.
    – oknate
    Commented Jan 22, 2018 at 21:55

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.