Description: Libre Office do not act the same way when it opens an odt wrongly tagged as docx and a docx wrongly tagged as odt. Steps to Reproduce: 1. take an odt file a.odt and rename it as a.docx 2. take a docx file b.docx and rename it as b.odt 3. open a.docx 4. open b.odt Actual Results: When opening a.docx (which is an ODF file) LO opens the file without notice. When opening b.odt (which is an OOXML file) LO complains that the file is corrupted and asks if LO should repair the file (with default answer set to No). If the user choose No, LO answer that the file could not be repaired and therefore cannot be opened. The user can only push the OK button and then LO opens the file without other notice. If the user choose Yes, LO answer the same thing but does not open the file. Expected Results: LO should notify the user that the format of the file does not comply with its extension. It should open the file without falsely saying that it is corrupted and it should give the correct type in the dialog File > Properties > General. Reproducible: Always User Profile Reset: No Additional Info: I cannot test old version of LO but I think that this is a very old problem inherited from OOo.
This problem is not hypothetical. I encountered it on a Seafile repository with online edition by OnlyOffice. A user created an odt file with LibreOffice and uploaded the file to the repository. Another user edited the file from the Seafile web interface. OnlyOffice imports the file and converts it to ooxml (2007 / 365) without renaming it in .docx. The next user synchronizes the library with a local folder and opens the file with his LibreOffice. And he says that LibreOffice is not able to open its own files :-( Best regards. JBF
The problem is that OOXML/MOX files can't be detected with examining magic bytes like for example ODF file can (that's why it is required mimetype file with appropriate content is at first place in the zip file). So when this detection fails we rely on the extension (I'm not completely sure what the detection does). To solve this issue we need to detect the type by checking the actual content: - check if it is a zip - if yes, check if it contains a file [Content-Types].xml, - if yes, we know it's a OOXML file but not which type, so parse the xml file to determine the type. This is far from a simple detection so we need to do it when magic detection fails. The trick is that we can easily detect it is a zip file and know it's not a ODF file just by looking at the magic bytes. As for the extension - yes, we should probably warn that the file doesn't use the correct extension.
Let's turn this into an enhancement then...