apache/hadoop · error · IOException

Failed to find <{expected}>; got {ev.asStartElement().getNam

Error message

Failed to find <{expected}>; got {ev.asStartElement().getName().getLocalPart()} instead.

What it means

When the reconstructor expects a literal tag name (anything not starting with '['), expectTag verifies the START_ELEMENT's local part matches; a different name throws this IOException naming both the expected and the actual tag. The tool walks a fixed section order (version, NameSection, INodeSection, ...), so a wrong element at a boundary means the document's structure no longer matches the dialect this oiv version emits.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/offlineImageViewer/OfflineImageReconstructor.java:217

        throw new IOException("Got unexpected attribute: " + ev);
      case XMLEvent.CHARACTERS:
        if (!ev.asCharacters().isWhiteSpace()) {
          throw new IOException("Got unxpected characters while " +
              "looking for " + expected + ": " +
              ev.asCharacters().getData());
        }
        break;
      case XMLEvent.END_ELEMENT:
        if (!allowEnd) {
          throw new IOException("Got unexpected end event " +
              "while looking for " + expected);
        }
        return ev;
      case XMLEvent.START_ELEMENT:
        if (!expected.startsWith("[")) {
          if (!ev.asStartElement().getName().getLocalPart().
                equals(expected)) {
            throw new IOException("Failed to find <" + expected + ">; " +
                "got " + ev.asStartElement().getName().getLocalPart() +
                " instead.");
          }
        }
        return ev;
      default:
        // Ignore other event types like comment, etc.
        if (LOG.isTraceEnabled()) {
          LOG.trace("Skipping XMLEvent of type " +
              ev.getEventType() + "(" +  ev + ")");
        }
        break;
      }
    }
  }

  private void expectTagEnd(String expected) throws IOException {
    XMLEvent ev = expectTag(expected, true);

View on GitHub (pinned to 2add963021)

Solutions

  1. Regenerate the XML with the same Hadoop version you will run ReverseXML with - XML and reconstructor must share a layout version
  2. Restore the expected tag name at the reported location; the message names both expected and actual tags
  3. Compare your file's top-level section sequence against a freshly generated dump (xmllint --xpath 'name(/*/*[N])' img.xml)

Example fix

<!-- before: section retagged -->
<NameSysSection><namespaceId>1</namespaceId></NameSysSection>

<!-- after -->
<NameSection><namespaceId>1</namespaceId></NameSection>
Defensive patterns

Strategy: validation

Validate before calling

# Section names must match this oiv version's dialect; spot-check the sequence
for s in version NameSection INodeSection; do
  xmllint --xpath "/fsimage/$s" fsimage.xml > /dev/null 2>&1 \
    || { echo "missing or renamed section <$s>"; exit 1; };
done

Prevention

When it happens

Trigger: ReverseXML where a section or child element was renamed, reordered, inserted, or removed around a section boundary; XML generated by a different Hadoop release whose section names/contents differ; splices of sections from two different dumps.

Common situations: Feeding a newer or older oiv's XML dump into this ReverseXML (the tool separately enforces matching <layoutVersion>); hand-retagging elements during edits.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/99093ebcdf7dcb90. Report an issue: GitHub.