I’ve figured it out what was wrong and I feel like a bit of an idiot for taking so long to figure it out. This is the issue and the solution is dead easy.
I was continuing work today after the testdownload worked fine, and then my new .xml files wouldn’t open again. The only difference was that the testdownload files were in C:\Seamus\Desktop, and my workfiles were buried in a long filepath in the C:\ drive.
I copied a work file and a previously unreadable CREODIAS file to D:\ and they both worked without issue.
(work file downloaded via SENET and copied to the D: Drive)
(CREODIAS Archive file downloaded from CREODIAS and copied to D: Drive)
The same file didn’t work with my original pathname (and even shortened it down with lots of ‘~’:
I looked into it happening in SNAP before and it’s the same problem as this earlier thread:
I already had the filepath extended workaround activated but there seems to be a consensus that the workaround just enables it only for programs that support it and that Windows Explorer doesn’t support it for legacy reasons.
So the problem was that my filepaths were way too long, and that Windows is old. That would also explain why the issue wasn’t reproducible as the files themselves were fine, it was just where I placed them that caused the problem!
For example, this was my original path for the xdfumanifest (with some characters changed for work reasons):
C:\Users\Seamus\Documents\Actual Documents\Work\CompanyXX\Remote Sensing XXXXX XXXXXXX Feasibility Study\Data\Trial Demonstration\Data Sources\Sentinel Imagery\Sent3\25Dec21\XXX\S3B_SL_2_LST____20211227T105138_20211227T105438_20211227T131107_0179_060_379_2340_LN2_O_NR_004.SEN3\xfdumanifest.xml
That’s 294 characters which Windows doesn’t like.
I’m sorry this took a lot of time to troubleshoot over something so trivial. Maybe Windows should warn when it might break things…