lsar JSON output is incorrect for double-format archives (.tar.gz, etc)

[GoogleCodeExporter]

lsar's JSON output is incorrect for double-format archives, like .tar.gz. The 
"lsarProperties" dictionary is not properly followed by a comma, even though 
it's now no longer the final entry in the top-level dictionary. See the 
following example, just above "lsarInnerFormatName". (This example contains 
only the item at index 0 of a tarball, to generate a short document, but it 
occurs when printing the entire document too.)

{
  "lsarFormatVersion": 2,
  "lsarContents": [
    {
      "XADCompressedSize": 512,
      "XADIndex": 0,
      "XADDataLength": 0,
      "XADDataOffset": 512,
      "XADSolidObject": "XADGzipHandle for \"/Users/mistydemeo/pip-1.5.4.tar.gz\", position 512",
      "XADIsDirectory": true,
      "XADPosixGroup": 20,
      "XADPosixPermissions": 493,
      "XADFileName": "pip-1.5.4",
      "TARIsSparseFile": false,
      "XADPosixUser": 501,
      "XADLastModificationDate": "2014-02-21 12:12:16 +0000",
      "XADFileSize": 0
    }
  ],
  "lsarEncoding": "US-ASCII",
  "lsarConfidence": 0,
  "lsarFormatName": "Gzip",
  "lsarProperties": {
    "XADVolumes": [
      "/Users/mistydemeo/pip-1.5.4.tar.gz"
    ],
    "XADArchiveName": "pip-1.5.4.tar.gz"
  }
  "lsarInnerFormatName": "Tar",
  "lsarInnerProperties": {
    "XADIsSolid": true,
    "XADArchiveName": "pip-1.5.4.tar"
  }
}

Original issue reported on code.google.com by mistyde...@gmail.com on 29 May 2014 at 5:55

[GoogleCodeExporter]

Original comment by paracel...@gmail.com on 29 May 2014 at 5:58

• Changed state: Accepted
• Added labels: Priority-High, Type-Defect

[GoogleCodeExporter]

Think I found the cause of it; will submit a patch.

Original comment by mistyde...@gmail.com on 29 May 2014 at 6:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Deleted previous comment.

Original comment by mistyde...@gmail.com on 29 May 2014 at 6:26

[GoogleCodeExporter]

I notice that the lsarProperties dictionary terminator is printed using 
endPrintingDictionary, which seems to explicitly not print a separator.

Original comment by mistyde...@gmail.com on 29 May 2014 at 6:54

[GoogleCodeExporter]

Is there a reason endPrintingDictionary sets needseparator to NO? It seems like 
it would be harmless, since I don't see anything else that might spuriously 
print a separator afterwards.

Original comment by mistyde...@gmail.com on 29 May 2014 at 11:16

[GoogleCodeExporter]

Simply setting needseparator to YES doesn't appear to cause any problems. It 
hasn't produced any spurious newlines or broken JSON in a few tests.

Original comment by mde...@artefactual.com on 4 Jun 2014 at 12:03

Attachments:

• json.patch

[GoogleCodeExporter]

I've been using this patch for several months now without any apparent issues. 
Do you think it's likely to cause any problems?

Original comment by mistyde...@gmail.com on 18 Sep 2014 at 9:36

[GoogleCodeExporter]

Probably not. Haven't had time to work on this for a while now so I haven't 
merged it yet, though, but I probably will once I get back to it.

Original comment by paracel...@gmail.com on 18 Sep 2014 at 9:53

[GoogleCodeExporter]

Seems there was another erroneous needsseparator=NO too.

I ended up simplifying the code a bit to make it a bit less confusing, and 
hopefully it should all be fixed now.

Unless I broke something while simplifying...

Original comment by paracel...@gmail.com on 20 Jul 2015 at 10:45

• Changed state: Fixed