Repository navigation
Current Prototype_1b header implementation issues #1152
Description
@DomCR, I am really not sure about the reliability and validity of the implementations in #1139 and #1150.
Essentially the entire Prototype_1b header logic seems to be full of assumptions.
This is unreliable at best and will corrupt DWG files at worst.
The reader appears to only search for the strings ACIS BinaryFile and ASM BinaryFile and tries to extract those bytes by guessing (and it checks if it would be "plausible" to be an ACIS file). This is error prone and could lead to false positives.
The writer portion seems to just build a generic Prototype_1b header that looks valid, but actually has nothing to do with the original header value of the original file. It is full of magic numbers and fixed values that are only valid under very specific circumstances. For example this is going to create issues with files containing multiple schemas or different schema names. Also it seems not to differentiate between blobs and data entries even though there are important size limits to adhere to.
I could open a PR with my implementation of a parser for the full Prototype_1b header in DWG files (including all data sections, ACIS data, thumbnails, etc). It would only include a reader and not a writer though. But the implementation is based on the ODA specifications and I tested it across hundreds of different DWG files. There still are a few unknown bytes (as in the ODA specs) as well as a few special cases which are missing from the ODA specs.
I do not want to make any accusations, but I get the feeling the aforementioned PRs were just AI generated.
Activity
ilCosmico commentedon Jul 14, 2026
Hi @domeitzinger, thanks for taking the time to look at this closely. A few clarifications, and I am glad to improve wherever the current approach falls short.
On the reader: the signature scan you describe was the original approach in #1139. Since then #1146 (merged) reads the payload area offset directly from the
_data_segment header, so that is now the primary path and the signature scan is only a fallback. In the common case the reader is no longer guessing.On the writer: it targets the payload that ACadSharp itself produces for 3DSOLID, REGION and BODY. I validated it by byte comparing the output against reference DWG files, and by opening the results in AutoCAD and DWG TrueView across the version matrix and for record counts from 1 to 12 (an off-by-one in the payload anchor at counts other than 9 was found and fixed exactly that way). The read side was exercised across a corpus of a few hundred DWG and DXF files with tens of thousands of payloads. So in every case I could test it does not corrupt files. That said, you are right that it writes the fixed schema set used for these entities rather than an arbitrary multi-schema header, and that is a fair limitation. If you have a file where the writer produces something invalid, please share it and I will fix it.
On the AI question: yes, I used AI assistance here, and I am happy to say so. I used it as a tool, with my own review and critical judgment, grounded in the reference files, data and documentation I had, and backed by testing. If you can share more data, or better still documentation, I will gladly use it to improve this further.
Your full specification-based parser sounds genuinely useful. A robust reader for the whole Prototype_1b header would be a better foundation than the current fallback, and since it is read only it does not overlap with the write side here. I would be glad to align on it, whatever works best for you and @DomCR.
domeitzinger commentedon Jul 14, 2026
Right, I overlooked that PR. But that does not change the fact that the guessing logic is still in place. It just also tries to find
_data_records and still does the guessing withblob01and the remaining_data_records it missed. So the only real change is instead of looking for theACIS BinaryFile/ASM BinaryFilestrings, it also searches for the_data_string. Therefore this is just even more guessing and checking what guess would be more plausible.Also I never said anything about the reader corrupting DWG files. The only way the reader could cause the DWG file to be corrupted is when it would pass invalid data to a writer implementation.
The
Prototype_1bheader is not at all as simple as the writer assumes. It is full of references and lookup tables that break the data stored in the header as soon as there is a wrong or missing reference. I cannot really say anything about the quality of the tests you mentioned you did, but I assume it has to be a small sample size. I have seen files with e.g. 2 or more schema definitions which are guaranteed to break with the current writer implementation. And there are many more issues with the writer: invalid file header data, invalid index records, invalid handling of blob data, just to name a few. There are many more problems with the current approach.And besides, especially for those not well documented areas of the AutoCAD specs, AI will hallucinate rules and generate code that might look like it is working, but actually
LLMs are just as good as their training data and for proprietary formats which lack public documentation, there simply is too much potential for it to output unreliable garbage data disguised as a working solutions. They can be quite useful, but they have to be handled with a lot of care and should never create implementations for structures they came up with by themselves without carefully reviewing, validating and understanding the code and its reliability.
DomCR commentedon Jul 14, 2026
Hi all,
I merged #1139 from @ilCosmico giving that it worked with the battery of files that I have at hand without any issue, but I also agree with @domeitzinger, the current implementation is not safe and if it fails during the reading process it will invalidate all the data.
I haven't look at the writer #1150 with detail yet, giving that the writer is a much more sensible part of the project and is really easy to output a corrupted dwg or dxf.
Now, before taking any move on this one, I'll open a PR to implement a safeguard during the reading
readAcDsData, (a simple try catch will do) in theDwgReaderandDxfReaderthat will avoid any corruption of data during the reading process. For the writer I want to take a deeper look myself on the reading process, @domeitzinger if you have an improvement I'll be happy to review it.Note: right now I'm in the middle of a breakthrough with the dynamic block parameters and I'll like to finish at least the dxf part, after that I'll jump on this.
Thank you both for your involvement in the project!
domeitzinger commentedon Jul 15, 2026
Thanks for taking a look at this.
Makes sense that it worked to get the ACIS data from most files. The current reader is not necessarily wrong per se, it is just a data extraction. It will only really cause issues when a file is large enough to be split across multiple
blob01records (especially when not stored sequentially). Then it could result in extracting corrupted ACIS / PNG files with mixed up byte chunks. Therefore in most cases you would not even notice that something could have gone wrong. But you would also never be able to reconstruct the Prototype1b section later, as all data has been ignored except for the bytes of the ACIS file contents.I have opened the PR #1154 with my implementation for full
Prototype1bsection parsing in DWG files.In the PR I leave the DXF extraction logic as it currently is. It might still be useful in its current state to try and get ACIS data (at least until implementing a section parser for the DXF side). Although the same concerns mentioned above still apply to DXF files.
ilCosmico commentedon Jul 15, 2026
Quick update on the reader side: I ran a comparison between current master and #1154 on our test collection (423 DWG files) and posted the results on the PR, together with two reproduction files. Happy to keep rerunning it as the branch evolves.
ilCosmico commentedon Jul 15, 2026
To close the loop on the writer side. I went through the writer field by field against chapter 24 of the ODA specification for .dwg files, version 5.4.1 (the AcDsPrototype_1b section), plus reference DWG files, including files saved by AutoCAD itself.
You were right that something was hiding in the index records. The search segment (24.2.2.7.1) stored each handle's directory position instead of its rank in the sorted handle order. The two coincide when the directory is already sorted by handle, which is why every file had opened fine so far. The fix is on #1150, with regression tests built from an AutoCAD-saved file whose handles are out of order.
The audit came back clean on the other points, as far as I could take it. Schema definitions: reading anchors on the data segment directory and does not depend on schema count or names; I checked it against AutoCAD-saved files with 2, 8 and 9 records. The schema segments the writer emits are the invariant blobs of a fresh save, byte-identical to AutoCAD's output. Blob data: the writer never pages to blob01, everything stays inline; this is documented in the PR as a known limitation, and DWG TrueView reads a 272 KB inline payload without complaint, so paging can come later when a real case needs it. On the file header I could not reproduce an invalid field, so if you have a file where the header or an index comes out wrong beyond the defect above, please send it over.
One more thing on validation, since sample size came up: I moved from round-trip checks to opening every model of our test suite in DWG TrueView with a forced view regeneration, because the modeler parses ACIS lazily and a file can open fine and still fail at the first regen. That pass surfaced more defects, most now fixed and one still open, but all of them in the payload generator that feeds this library, not in the AcDs writer.
On a personal note, I'm glad this is turning into a collaboration rather than a contest. The section ends up better with more eyes on it 🙂