Page History

...

If the same filename is repeatedly created and deleted within the same parent directory, then the deleted files will have conflicts when moved into the pFID directory in the Trash Can.   This may happen for files that are edited by the user, and a temporary file like .FILENAME.tmp12345 is created and written by the editor, and then renamed over the original FILENAME (causing it to be deleted) so that the file contents are not lost if the new file is only partially written.  In such cases, the same FILENAME may be deleted many times.

To disambiguate the files in Trash, the conflicting filenames should be disambiguated by appending a timestamp to the filename, like filenameFILENAME.2025-04-03-00:11:24, possibly adding .microseconds if there is still a conflict.  It isn't totally clear whether it would be better to use the timestamp from when the file was deleted, or when the file was created.  Both have some value to help users distinguish between the different versions.

...

Files that only exist for a very short time (e.g. temporary files) should not necessarily be preserved in the Trash Can, or they can quickly overwhelm the available capacity of the filesystem, and result in important files being purged from trash and/or filling the trash faster than files can be cleaned up. Files marked with the I_LINKABLE flag on the MDS (from O_TMPFILE, or Lustre Volatile files, see LU-18844) should not be preserved in the Trash Can if they are not linked into a file in the namespace.  It would be useful to have a tunable parameter that sets a minimum age for files to be preserved in the Trash Can (e.g. 65 minutes?) so that files that are frequently created and deleted are not preserved since they could consume a considerable amount of space.

...