When a DICOM file contains two meta information segments, the second segment overwrites the first

[amoerie]

Describe the bug
When a DICOM file is opened that has multiple instances of group 0x0002 (= File Meta Information),
the file meta information is taken from the last instance instead of the first.
I'm aware that this file is technically invalid, but we see instances of this in the wild and other tools like dcmdump can properly handle them.
We noticed this because, when trying to render such a DICOM file, the wrong transfer syntax (from the 2nd segment) is used by fo-dicom.

To Reproduce
I will add a unit test that demonstrates the problem, once I figure out how to anonymize the sample file properly.

Expected behavior
The second (and any other) instances of that group should be considered tags belonging to the data, not the meta information.

Environment
Fellow Oak DICOM version: Latest 5.x
OS: Any
Platform: Any

[gofal]

when using anonymizer-tools to anonymize invalid files, then those tools often sanitize or repair the file implicitly.
I usualy anonymize such files, by opening them in a hex-editor (HxD or similar) and replace the Characters containing names by other Characters, so that the patientsname finally is something like "AAAAAAA^BBBBBBBBBBB" and all the content-lengths of offsets still are valid

[amoerie]

Thanks for the advice! I found that dcmodify handled it correctly, so I just used that to anonymize the names and remove the private tags. I've created a PR already :-)

[amoerie]

I'm marking this as "enhancement" because if we're really fair, the DICOM file is mostly at fault, but I simply ensured that fo-dicom can deal with these kind of faulty files.

[mrbean-bremen]

As I just wrote in a pydicom issue created due to another invalid DICOM data related problem: Every possible violation of the DICOM standard will appear in the wild some day... 😬