View Issue Details

IDProjectCategoryView StatusLast Update
0016851mantisbtattachmentspublic2016-07-11 15:48
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.2.15 
Summary0016851: Downloading, viewing, and checking existence of attachments should get attachment location from db

At the moment if a user changes the attachment storage from DISK to DATABASE or vice versa and ends with a mix, then the code will behave based on the latest config, rather than handling each attachment based on where it is saved.

Ideally, all attachments are stored on DISK or DATABASE, but it is good to handle the transition case.





2014-01-19 06:47

developer   ~0039083

Last edited: 2014-01-19 06:48

View 2 revisions

This approach would hide some way that there is a problem with the MantisBT instance.
I prefer getting problems if there is a (hidden) problem.

If the setting is DATABASE, administrators expect that the database contains all data and they expect that making a backup of MantisBT is nothing more than backing up the database.
They would also expect that moving an instance from one system to another is mainly export and import of the database.



2014-01-19 14:09

manager   ~0039087

I think it is annoying that we don't have a reliable / fast way right now to figure out where an attachment is stored. I think we should update the schema or the way we use it to quickly figure out what's going on. Then we can decide to support the scenario where there is a mis-match or recommend that users use a script like move_attachments.

Your argument about administrator not knowing about the problem, will happen even if we show as broken, since users will only know about it when they open specific issues.

Also including the pull request link:



2014-05-27 01:22

manager   ~0040646

I also noticed today that if an admin runs the system utils to export attachments from database to disk on a MySQL database, the code will expose 2 byte files for attachments that were saved on disk and will link to those new 2 byte files instead of the real ones that exist on the attachments folder and were linked before. The ones that were in the database will be exported and linked properly.



2014-06-01 17:20

reporter   ~0040700

I'm not sure if it helps towards this issue, but when looking at this 1.3 blocking issue earlier today, and a similar issue I now can't find that damien commented on - I've added code to move_attachments.php to handle moving from disk to db and db to disk.

Will generate a PR for that once I've caught up with dregad.

It's not going to fix the user case (victor describes), nor whatever victor means with the 2 byte files - but upon seeing "attachment missing" in my local dev box, and going to move attachments system utility I've moved some files from disk<>db and back to disk successfully.

Assuming that damien is happy with what I've done to his code, and that people are happy with the pull request for that, would that be enough to resolve this bug?

In short, the admin page displays attachments:

in db / attachments on disk / move to db / move to disk

as 4 - therefore admin can see if the attachments are in a inconsistent state and fix. What it doesn't do is try to be clever around viewing the issue by 'searching' for possible matching content.

Issue History

Date Modified Username Field Change
2014-01-19 04:06 vboctor New Issue
2014-01-19 04:06 vboctor Status new => assigned
2014-01-19 04:06 vboctor Assigned To => vboctor
2014-01-19 06:47 atrol Note Added: 0039083
2014-01-19 06:48 atrol Note Edited: 0039083 View Revisions
2014-01-19 14:09 vboctor Note Added: 0039087
2014-01-19 15:13 vboctor Tag Attached: patch
2014-04-12 22:58 vboctor Assigned To vboctor =>
2014-04-12 22:58 vboctor Status assigned => new
2014-05-27 01:22 vboctor Note Added: 0040646
2014-06-01 17:20 grangeway Note Added: 0040700
2014-12-08 02:10 atrol Target Version 1.3.0-beta.1 => 1.3.0-beta.2
2015-03-15 19:59 dregad Target Version 1.3.0-beta.2 => 1.3.0-beta.3
2015-09-06 17:47 vboctoradmin Target Version 1.3.0-beta.3 => 1.3.0-rc.1
2015-12-06 02:55 vboctor Target Version 1.3.0-rc.1 => 1.3.0-rc.2
2016-06-12 02:37 atrol Target Version 1.3.0-rc.2 => 1.3.0
2016-07-10 07:57 atroladmin Target Version 1.3.0 => 1.3.1
2016-07-11 15:48 atrol Target Version 1.3.1 =>