Make Automatic File Cleanup Optional When file_usage drops to 0

[bennybobw]

Description of the need

There is some concern that file_usage_delete marks files for deletion when that's breaking change behavior from Drupal 7.

@quicksketch mentioned that it's nearly impossible to delete files in D9/D10/D11 and he wants to avoid that. I think this could easily be gotten around by allowing files to be deleted directly by allowing file deletion from admin/content/files

Over in #3857#issuecomment-2880006337 @GeoTimber wrote

Hi @argiepiano, thanks for you reply,

Having permanent managed files with usage = 0 is an anomaly and should not happen in normal operations of Backdrop sites. Even when you create a file entity by uploading a file through the Manage files UI (admin/content/files), the file usage for the new file becomes = 1 , even though that file is technically not "used" anywhere in the site other than as a file entity. In fact there is code in Backdrop that will eliminate files when their use becomes 0

So you say during the migration I should create a file usage record for the file entities I want to keep and that did not have a file usage record already?

As suggested here ? #Backdrop > File may not be referenced in WYSIWYG @ 💬

Still i am not in favour of auto cleanup, or not being able to revive a file if it is no longer used.

* I think the cleanup should be a configurable cron job running on x day old files, meanwhile you can re-use the non-used file, or turn the cleanup feature  off.

* And if Drupal 7 did not delete unused files the cron job to cleanup/delete files should be turned off by default doing a migration  to maintain compatibility.

* And the migration should not have left the files in an invalid state, if you cant have a permanent managed file without a file usage record then it needs to be solved before the import is completed.

The problem is probably caused by modules not registering their file usage properly or a bug in the registration in D7.

So the idea here I guess is to add a config option that you can toggle on/off for this particular part of file_usage_delete:

// If there are no more remaining usages of this file, mark it as temporary,
  // which result in a delete through system_cron().
  $usage = [file_usage_list](https://docs.backdropcms.org/api/backdrop/core%21includes%21file.inc/function/file_usage_list/1)($file);
  if (empty($usage)) {
    $file->[status](https://docs.backdropcms.org/api/backdrop/1/search/status) = 0;
    $file->[save](https://docs.backdropcms.org/api/backdrop/1/search/save)();
  }

I don't like turning off the cron job that does it because it still means these files would be marked as temporary in file_managed

[indigoxela]

Currently lots of that handling's simply hardcoded. Making it configurable in some way, even if it's only a hidden config item, would allow for more flexibility. And / or add a hook to function file_usage_delete()?

The idea re config: if that (newly introduced) config says "no automatic file garbage collection", then the file does not get marked "temporary", but we still need a usage, so... file_usage_add($file, 'file', 'file', $file->fid);

Disadvantage of the "self-referencing" approach: it can't be undone. That file will be permanent forever (or until manually deleted by intention via admin UI). Even if later on the garbage collection gets turned on again.

Entirely turning off garbage collection only to hide a core bug seems the wrong motivation to me, but adding the ability to toggle it on/off, or tweak details (like BACKDROP_MAXIMUM_TEMP_FILE_AGE) seems beneficial.

How much UI we add for that in core... to be determined.

[bennybobw]

Entirely turning off garbage collection only to hide a core bug seems the wrong motivation to me, but adding the ability to toggle it on/off, or tweak details (like BACKDROP_MAXIMUM_TEMP_FILE_AGE) seems beneficial.

I don't this issue is about a core bug. This is a feature request for file_usage_delete so that it won't automatically set files with no file_usage to temporary in the file_managed table.