apache/hadoop · error · IOException

Unexpected stat output: " + line

Error message

Unexpected stat output: " + line

What it means

Thrown in Stat.parseExecResult when parsing the numeric CSV fields of stat output (size, mtime, atime, block size) raises NumberFormatException. The shell emitted a line that passed the error-string checks but is not the expected GNU/BSD numeric format, so Hadoop wraps the parse failure with the offending line for diagnosis.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/Stat.java:166

      // 'notalink'
      // `link' -> `target' OR 'link' -> 'target'
      // '' -> ''
      Path symlink = null;
      String parts[] = symStr.split(" -> ");      
      try {
        String target = parts[1];
        target = target.substring(1, target.length()-1);
        if (!target.isEmpty()) {
          symlink = new Path(target);
        }
      } catch (ArrayIndexOutOfBoundsException e) {
        // null if not a symlink
      }
      // Set stat
      stat = new FileStatus(length, isDir, 1, blockSize, modTime, accessTime,
          perms, owner, group, symlink, qualified);
    } catch (NumberFormatException e) {
      throw new IOException("Unexpected stat output: " + line, e);
    } catch (NoSuchElementException e) {
      throw new IOException("Unexpected stat output: " + line, e);
    }
  }
}

View on GitHub (pinned to 2add963021)

Solutions

1. Run the exact command Stat builds (stat -c '%s,%F,%Y,%X,%a,%U,%G,%N' path) and compare with the expected CSV
2. Force a POSIX locale for the JVM process (LANG=C, LC_ALL=C) so number formatting is predictable
3. Replace Stat with java.nio.file.Files.readAttributes, which avoids shell parsing entirely

Example fix

// before: rely on shell `stat` parsing
FileStatus st = new Stat(path, false, shell).getFileStatus();

// after: locale-proof Java NIO
java.nio.file.attribute.PosixFileAttributes a = java.nio.file.Files.readAttributes(
    java.nio.file.Paths.get(path.toString()),
    java.nio.file.attribute.PosixFileAttributes.class);

// deterministic formatting before relying on shell stat
// launch the JVM with -Duser.language=en / LANG=C, LC_ALL=C
// or skip the shell entirely:
java.nio.file.attribute.PosixFileAttributes a = java.nio.file.Files.readAttributes(
    java.nio.file.Paths.get(path.toString()),
    java.nio.file.attribute.PosixFileAttributes.class);

try {
  st = stat.getFileStatus();
} catch (IOException e) {
  // "Unexpected stat output: <line>" -> inspect <line>: locale? non-GNU stat?
  st = fallbackViaNio(path);
}

When it happens

Trigger: A locale or stat variant that formats numbers differently (localized output), a localized error message that does not match the hard-coded English 'No such file...' suffixes and falls through to parsing, or unexpected text (wrapper banner, SELinux audit noise) prepended to the line.

Common situations: Running with unusual LANG/LC_ALL settings; minimal container images shipping busybox or toybox stat whose output format differs from GNU coreutils; hosts where a site wrapper script replaces /usr/bin/stat.

Related errors

• Unexpected empty line
• value cannot be blank
• ${value} is not in expected format.Expected format is <numbe
• No version in key path ${versionName}
• Expecting additional output after line: ${line}

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