Project

General

Profile

Actions

Defect #33769

closed

When creating more than two identical attachments in a single db transaction, the first one always ends up unreadable

Added by Jens Krämer over 4 years ago. Updated about 4 years ago.

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

0%

Estimated time:
Resolution:
Fixed
Affected version:

Description

Due to the file re-using code running in an after_commit hook, the hooks of any attachments that are created in a common db transaction will be deferred and run one after another after the outer transaction was committed. The existing implementation does not take that into account and as a consequence, when creating more than two identical attachments in a single transaction, the first attachment will end up with a non-existing diskfile.

The attached patch includes a test reproducing the issue and a fix, which consists of using last instead of first when finding an existing attachment to re-use. This way, the selected attachment is consistent across all runs of the hook even if multiple candidates exist. I also added an explicit order call for good measure.

This is a corner case that should never occur in normal Redmine usage - but may occur in 3rd party code that's creating many attachments wrapped in a transaction.


Files


Related issues

Has duplicate Redmine - Defect #28440: After commit missing fileClosed

Actions
Actions #1

Updated by Go MAEDA about 4 years ago

  • Target version set to 4.0.8

Setting the target version to 4.0.8.

Actions #2

Updated by Go MAEDA about 4 years ago

Actions #3

Updated by Go MAEDA about 4 years ago

  • Tracker changed from Patch to Defect
  • Status changed from New to Resolved
  • Assignee set to Go MAEDA
  • Resolution set to Fixed

Committed the fix. Thank you for your contribution.

Actions #4

Updated by Go MAEDA about 4 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF