fisher 20110808 diskfile content in DB missing the filepath prefix

I believe that the solution you propose for point 3 is not correct.

$c_unique_name is the filename, without path, of the attachment (MD5 hash) that will be stored on disk; as you found out it is stored in mantis_bug_file_table.diskfile.

The path is stored separately in mantis_bug_file_table.folder. When uploading the attachment, this path is taken from the project's "Upload File Path" or, if unspecified, from global configuration $g_absolute_path_default_upload_folder.

I can think of the following scenarios:

• the project's upload file path is incorrect or not set
• the global path is not set
• or maybe your attachments have been moved

You did not specify if the problem occurs with new attachments or with existing ones. In any case I am not able to reproduce the behavior with a fresh 1.2.6 install.

==>I can think of the following scenarios:

• the project's upload file path is incorrect or not set
  there is no project specific upload file path setting
• the global path is not set
  the global path is set as we migrated from the old version 1.1.6
• or maybe your attachments have been moved
  the attachment not moved

let me try to elabrate the situation more clearly as below.
I just recently upgraded from 1.1.6, the attachment files for migrated existing issues are OK, but for new attachment for either existing issue or new issue has the reported problem (show attachment missing after upload).
after changed the source code file file_api.php , the problem solved.

I managed to reproduce your problem by removing the trailing / in $g_absolute_path_default_upload_folder.

As documented in config_default_inc.php, the trailing / is mandatory:

• absolute path to the default upload folder. Requires trailing / or \

Even though you have found a working solution, I suggest that you revert your code changes and set your config_inc as appropriate to avoid future maintenance issues.

I guess the code could be improved to properly handle paths without the trailing /, I'll see if that can be done.

Now to fix the problem for any "lost" attachments:
During testing, I noticed as I had set $g_absolute_path_default_upload_folder = '/tmp/attach' that files were actually (and logically) created in /tmp with a name like attachXXX (where XXX is an MD5 hash). Assuming these files still exist on your system

• move them to the actual attachments directory
• rename them to remove the prefix "attach" (or whatever your actual folder name is)

Finally, a couple of suggestions to facilitate handling of any future bug reports:

• try to stick with 1 problem = 1 issue on the tracker (here you have 3 in 1)
• provide relevant config_inc settings as part of the bug report

the relevant setting in my config_inc.php is as following
$g_file_upload_method = DISK;
$g_absolute_path_default_upload_folder = 'D:/uploadfile/database';
Per your suggestion, I changed the setting to
$g_file_upload_method = DISK;
$g_absolute_path_default_upload_folder = 'D:/uploadfile/database/';
and reverted the code in file_api.php back, try to upload file again, the same problem , but after changed the source code, then problem solved.
So it seems that the problem is not related to configuration (whether with or without trailing /),but the source code in file_api.php, because the variable name t_disk_file_name other than c_unique_name should be mapped to the table field diskfile.

I would like to take this opportunity to thank you for your quick response to my issue report considering the open source nature of this software. hopefully mantis will make big progress in the future.

You're welcome.

So you're on Windows... Just a tought (untested, as I don't have any available environment) - the standard delimiter on this OS is "\" not "/" so you may want to test with

$g_absolute_path_default_upload_folder = 'D:\uploadfile\database\';

the variable name t_disk_file_name other than c_unique_name should be mapped to the table field diskfile.

This is on purpose, both to avoid duplicate file names and for security reasons.