GetLogs from io.Manager returns a .z01 or .zip.001 file that won't open

io.Connect Desktop
1

Symptom

Running GetLogs from io.Manager against a machine with a lot of logs returns a single ReportingFiles_attachments.z01 or reporting_files.zip.001, depending on the version and configuration. The file can’t be unzipped since it’s not a valid zip file.

Cause

The platform splits the log archive into 10 MB parts, and GetLogs sends io.Manager only the first one. The part size comes from issueReporting.mail.maxAttachmentMB, shipped by default as "10". Despite sitting under mail, it applies to GetLogs whether or not mail reporting is enabled. Splitting starts when the compressed archive, not the log folder, passes 10 MB: in one test, 138 MB of logs made an 11.6 MB archive. This issue is our backlog.

Workaround

Set the "maxAttachmentMB" key to "0" to turn splitting off, in io.Connect Desktop’s system.json (or the source you deploy configuration from). Restart io.Connect Desktop, then run GetLogs again:

"issueReporting": {
    "mail": {
        "maxAttachmentMB": "0"
    }
}

Keep the quotes, since the value is a string, and leave your other mail settings as they are. Deleting old logs instead only postpones the split.

The same key caps the attachment size for Feedback sent by email. If you send Feedback by email and your mail server limits attachment size, set the key to that limit in MB instead of "0"; GetLogs stays whole while the archive is comfortably below that limit.

Already have a .z01 or .zip.001?

Windows’ built-in tar extracts the files archived before the 10 MB cut:

tar -xf reporting_files.zip.001

It exits with an error at the file that straddles the cut. That file comes out incomplete (cut short, or in a .z01 padded to full size with zeros), and the files before it are whole. Which files land in the first part depends on archive order, so the log you need may not be there. After the fix, run GetLogs again for the complete set.

Reported on io.Connect Desktop 10.5.0 and 10.5.2 on Windows.

1 Like