Closed Bug 1564493 Opened 5 months ago Closed 5 months ago

Attachments mysteriously deleted since upgrade to bugzilla 5


(Bugzilla :: Attachments & Requests, defect, critical)

Not set





(Reporter: austin.france, Unassigned)


(Keywords: dataloss)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Steps to reproduce:

Attach files to bugzilla after upgrading from bugzilla 3.4 to bugzilla 5.0.

Investigation has shown that the first instance of this issue is for attach_id 46240.

select min(id) from bugs.attach_data where length(thedata) = 0;

I still have a copy of the bugs 3.4 database that was used to upgrade, and the last attachment in the old db (ie prior to upgrade) was 46225. Therefore it is only attachments added post upgrade that are having this issue.

Actual results:

Attachments are either not attached properly or are later removed (thedata set to null). It is unclear at this point if the attachment ever made it onto the system, but there have been no reports and no indication of errors when adding attachments, but have started getting reports of missing attachments when people are coming back to their bugs to view the attachments.

Expected results:

Attachment should be attached and remain attached and not be deleted (set to null).

I can't even find a way to delete attachments in bugzilla! I don't see a delete option anywhere.

If it is only attachments added post upgrade that are affected, does this suggest the problem is likely linked to adding the attachment rather than something coming along later and deciding to remove an attachment?

After some investigation (reading the code), I have found the issue.

I seems since the upgrade to 5.0, bugzilla stores some attachments in data\attachments rather than in the database.

Our bugzilla server died at the end of last month, but we maintain a mirror VM with a slave mysql server replicating our bugzilla database (or so we thought) so were able to copy the slave VM and tweak it into becoming the new master. This worked perfectly (we thought) and we didn't lose a single bit of data because when the server died, mysql was in sync.

However, we had not realised bugzilla was now storing some attachments on the file system (though we do have a separate nightly backup of the filesystem). We also managed to revive the old master server, and I was able to recover the missing attachments from there, I just merged them into the attachments folder on the live server.

Q. Is storing some attachments (seems to be about 1 in 20 or so) on the file system the intended behaviour?
Q. Is it possible to turn this feature off and only ever store them in the database?

In the mean time, I will arrange for the data/attachments folder to be mirrored.

Closing this as INVALID.

Turns out the reason for the difference in behaviour after our 5.0 upgrade is because maxattachmentsize was set to 1000 in the new version, and 3000 in the old version.

We still need to deal with potential attachments in the data/attachments folder ofc

Closed: 5 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.