How do I debug when Writer fails to open a document?

[_savage]

Hi, I’ve got a DOCX file which opens without problems in Word and also in LO when opened directly like so:

Code: Select all

soffice /path/to/test.docx 

However, when I try to open that same file in a headless LO instance using Python & UNO, it comes back empty:

Code: Select all

>>> import uno
>>> local = uno.getComponentContext()
>>> resolver = local.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", local)
>>> context = resolver.resolve(f"uno:pipe,name=soffice-pipe-f0a6bad0-9764-4d18-82cc-7ba93591bacd;urp;StarOffice.ComponentContext")
>>> desktop = context.ServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop", context)
>>> # Passing the `RepairPackage` property doesn't work either!
>>> document = desktop.loadComponentFromURL("file:///path/to/test.docx", "_blank", 0, ())
>>> document  # None
>>> 

No logging, no errors, nothing. There are instructions on how to build a debug version of LO but I’d rather not dig through that. So, what can I do from here?

Thanks!

[RoryOF]

For testing, can you open an .odt document and also a different (even trivial) .docx document using the same code? If not, the problem is most likely in the code, not in the documents.

[_savage]

The code isn’t the problem: I’ve been using these same Python scripts almost untouched for years and I’m able to open pretty much any other document.

Interestingly, if I load that DOCX into a recent version of Word and save, that resulting DOCX also opens without problems. There seems to be something odd with that particular DOCX file…

[RoryOF]

Try unzipping the bad copy of the file and the good copy, and see if you can visually identify any obvious differences.

[keme]

Just a thought: Is that "bad" document file really a link, pointing to a file somewhere else in the file system. Modern user environments tend to mask that distinction, so file-open goes smoothly, but lower level operations (like your code) does exactly what you instruct them to do.

This type of situation has had me fooled in a couple of occasions (backup tools saving a bunch of useless link files; actual data files lost).

[_savage]

Try unzipping the bad copy of the file and the good copy, and see if you can visually identify any obvious differences.

Phew… Both contain the same number and types of files, though the bad copy’s XML files are generally (much) shorter. I did not check whether the XML is valid and how the content itself compares but nothing stood out to me.

Just a thought: Is that "bad" document file really a link, pointing to a file somewhere else in the file system.

It indeed is a link to the actual file, but that hasn’t been a problem in the past for my scripts. In production — where this failed originally — it’s not a link.

[keme]

[...]
It indeed is a link to the actual file, but that hasn’t been a problem in the past for my scripts. In production — where this failed originally — it’s not a link.

Of course. My bad! I guess MacOS will use proper (file system level) links, not the "OS level" linking (link files;".lnk" extension) you find in MS Windows (which is the OS of choice for most of my user base). Disregard my thought above.