サービスモジュールを使用してREST APIを実装しています。1つのリソースで、アップロードされたファイルのPOSTが許可されます。サービスの前処理機能中に、ファイルを一時ディレクトリに保存します。サービスの後処理機能中に、ファイルをプライベートディレクトリに移動し、file_usage_addを呼び出して、ホストエンティティを保存します。一時ファイルの保存と永続的な場所への移動の間に検証エラーが発生した場合、一時ファイルを明示的に削除していません。このファイルのエントリがfile_usageに存在しないため、drupal cronがこれを処理してくれると思いました。しかし、cronがこれを処理してくれているようには見えません。これがなぜなのかについての考えはありますか？
file_managedを確認すると、削除したい一時ファイルが表示されます。file_usageを確認したところ、対応するレコードがありません。
更新-追加の情報：ほとんどの場合、ファイルは実際にはありません。これは、OSの再起動により/ tmpディレクトリがクリアされたためと考えられます。いずれにしても、実際のファイルが見つからなくなった場合、system_cronはファイルのfile_managedエントリを削除しますか？
この問題は、ネイティブモバイルアプリからファイルのアップロードを開始してから発生しました。ファイル名はすべてのアップロードで同じです。一時ファイル名が/ tmpディレクトリに存在しない場合がありますが、file_managedのレコードはそのファイル名のURIでまだ存在します。そのため、file_managedテーブルを保存すると、整合性エラーが発生します。アプリを更新してランダムなファイル名を作成する予定です。それまでの間、データベースと、これらのファイルを管理する周囲の「接着」ロジックをクリーンアップしたいと思います。system_cronが私のためにそれをすべて行うなら、それは素晴らしいことです。しかし、私が言えることから、system_cronはfile_managed内の古い、完全に未使用の（および参照されていない）レコードを削除していません。