Moved files should not be new code - only changed lines!

I have (another) project where the new code definition is not working as desired.

I am working on a legacy code base. One of the changes in my pull request restructures the code by moving source files from location A to location B.

Bug 1: This seems to make the entire code base be treated as new code.

The git blame information is however correct in sonar. Like git, it shows when lines were actually changed but…

Bug 2: it fails the quality gate due to existing security and reliability issues which I do not want to fix as part of this PR.

A pull request should only fail the quality gate if new code introduces new issues.

I think this may be a duplicate of Old code appearing as new code when moving the file to a different package
but that ticket does not provide any workaround or acknowledge this as a defect.

Q If this is a temporary problem caused by the rename what is the correct way to ignore those issues for the PR without labelling them as resolved / reviewed for the main branch?
(this would be a possible workaround)

E.g. we mark them as “confirmed” or something.
Next time the main branch code is analysed or the code is changed they are still listed as requiring review etc.

Is there a way to view the change information that a sonar analysis is actually using to help debug issues with new code detection?
With with sonar.verbose=true the most I can get is, for example:

20:11:02.856 DEBUG: /home2/brucea/work/git/dcs/src/main/c/dcs/dcs_arch.c not marked as unchanged: file content changed

Which does not actually tell me how many lines were detected as changed.

Hello @KantarBruceAdams,

Thank you for reaching out!
Unfortunately, the answer that I can provide is similar to the thread you already mentioned.
There is no way to debug new issues detection on the scanner side.