| Description | file_move_bug_attachments() derives each attachment's source location from
the source project's current file_path, ignoring the folder column that
records where the file was actually written. The function also writes
folder at the end of each move, so it disagrees with itself: it maintains a
column it never reads.
project_update() lets an administrator repoint a project's file_path
without moving the attachments already on disk. From that point on, moving an
issue out of that project looks for its attachments in a directory that never
held them, with two distinct outcomes:
-
Normally, rename() and then copy() both fail, and the move aborts with
ERROR_FILE_MOVE_FAILED ("Unable to move file to ..."). The issue cannot be
moved at all.
-
If the two projects' configured paths happen to be equal, the early
if( $t_path_from == $t_path_to ) return; skips the move entirely. The
attachment is left in its old directory and folder still points there,
even though the issue now belongs to a project whose uploads live elsewhere.
That early return is wrong in principle as well as in this case: it compares
two projects' configuration, which says nothing about where any particular
attachment actually is. |
|---|
| Steps To Reproduce | With $g_file_upload_method = DISK:
- Create project A with
file_path = /mnt/a/ and project B with
file_path = /mnt/b/.
- Attach a file to an issue in project A. It is written to
/mnt/a/ and
folder records /mnt/a/.
- Edit project A and change its file path to
/mnt/c/ (any existing writable
directory). Existing attachments are not moved, as expected.
- Move the issue to project B.
Result: the move fails with "Unable to move file to /mnt/b/<diskfile>".
For the second variant, at step 3 set both projects' file paths to the same
new directory, then move the issue: the move reports success, but the file is
still in /mnt/a/ and folder still says /mnt/a/. |
|---|
