Project

General

Profile

Actions

Patch #34479

closed

Fix possible race condition with parallel, identical file uploads

Added by Jens Krämer over 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Attachments
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

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


Files

Actions #1

Updated by Go MAEDA about 3 years ago

  • Target version set to Candidate for next major release
Actions #2

Updated by Andriy Lesyuk about 3 years ago

We had a situation, when several files with the same name were uploaded at the same time. All they got the same disk filename.
As a result different container objects now point to the same file, which should actually belong to only one of them. Other files got lost (overridden).

Actions #3

Updated by Go MAEDA about 3 years ago

  • Target version changed from Candidate for next major release to 4.1.2

Setting the target version to 4.1.2.

Actions #4

Updated by Marius BĂLTEANU about 3 years ago

All tests pass with the patch applied on the current trunk: https://gitlab.com/redmine-org/redmine/-/pipelines/270891057

Actions #5

Updated by Go MAEDA about 3 years ago

  • Status changed from New to Closed
  • Assignee set to Go MAEDA

Committed the patch. Thank you.

Actions #6

Updated by Jens Krämer over 2 years ago

Andriy Lesyuk wrote:

We had a situation, when several files with the same name were uploaded at the same time. All they got the same disk filename.
As a result different container objects now point to the same file, which should actually belong to only one of them. Other files got lost (overridden).

see #35539 for a patch fixing this.

Actions

Also available in: Atom PDF