There is a race condition with multiple application processes when uploading multiple identical files at the same time, which may lead to attachments pointing to files that do not exist, if attachment creation and deduplication are executed in a particular order:

• Attachment A0 exists in the system.
• identical Attachment A1 is created in one process
• identical Attachment A2 is created at the same time in another application process
• for some reason, A2 is deduplicated before A1 and now points to A1's diskfile
• A1 is deduplicated and now points to A0's diskfile

Since during deduplication of A1, A1's original disk file is deleted, A2 now points to a non existent file.
To fix that, an additional check whether the file really is not referenced anymore before deleting it is introduced.

In plain Redmine usage scenarios this is really a very unlikely scenario, but we had it happen with our WebDAV integration where whole directory trees can be uploaded at once. Should the issue indeed have manifested itself somewhere else, it can easily be fixed by finding unreadable attachment records, using the digest to find an identical, readable attachment and correcting the disk location accordingly:

unreadables = Attachment.all.reject(&:readable?)
unreadables.each do |u|
  if readable = Attachment.where(filesize: u.filesize, digest: u.digest).detect(&:readable?)
    u.update_columns disk_directory: readable.disk_directory, disk_filename: readable.disk_filename
  end
end