View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016851||mantisbt||attachments||public||2014-01-19 04:06||2016-07-11 15:48|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0016851: 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.
This approach would hide some way that there is a problem with the MantisBT instance.
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.
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:
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.
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.
|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 =>|