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
Description

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.

Tagspatch

Activities

atrol

atrol

2014-01-19 06:47

developer   ~0039083

Last edited: 2014-01-19 06:48

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.

vboctor

vboctor

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:
https://github.com/mantisbt/mantisbt/pull/108

vboctor

vboctor

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.

grangeway

grangeway

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.