apache/hadoop · error · UnsupportedOperationException

{getClass().getCanonicalName()} does not support listCorrupt

Error message

{getClass().getCanonicalName()} does not support listCorruptFileBlocks

What it means

Corrupt-block tracking is an HDFS concept (the NameNode records blocks whose replicas fail verification); AbstractFileSystem.listCorruptFileBlocks defaults to UnsupportedOperationException, and only the HDFS AFS (plus pass-through wrappers like FilterFs/ChRootedFs/ViewFs) overrides it. FileContext exposes the same call at fc.listCorruptFileBlocks(path), so health tools hit this on every non-HDFS backend.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/AbstractFileSystem.java:1222

   * @throws AccessControlException access control exception.
   * @throws FileNotFoundException file not found exception.
   * @throws UnresolvedLinkException unresolved link exception.
   * @throws IOException raised on errors performing I/O.
   * @return FileStatus Iterator.
   */
  public abstract FileStatus[] listStatus(final Path f)
      throws AccessControlException, FileNotFoundException,
      UnresolvedLinkException, IOException;

  /**
   * @return an iterator over the corrupt files under the given path
   * (may contain duplicates if a file has more than one corrupt block)
   * @param path the path.
   * @throws IOException raised on errors performing I/O.
   */
  public RemoteIterator<Path> listCorruptFileBlocks(Path path)
    throws IOException {
    throw new UnsupportedOperationException(getClass().getCanonicalName() +
                                            " does not support" +
                                            " listCorruptFileBlocks");
  }

  /**
   * The specification of this method matches that of
   * {@link FileContext#setVerifyChecksum(boolean, Path)} except that Path f
   * must be for this file system.
   *
   * @param verifyChecksum verify check sum flag.
   * @throws AccessControlException access control exception.
   * @throws IOException raised on errors performing I/O.
   */
  public abstract void setVerifyChecksum(final boolean verifyChecksum)
      throws AccessControlException, IOException;
  
  /**
   * Get a canonical name for this file system.

View on GitHub (pinned to 2add963021)

Solutions

  1. Restrict the call to hdfs:// paths by checking the scheme before invoking
  2. For real checks use 'hdfs fsck' or DistributedFileSystem.listCorruptFileBlocks() on an HDFS client
  3. Probe the path capability CommonPathCapabilities.FS_LIST_CORRUPT_FILE_BLOCKS via hasPathCapability before calling

Example fix

// before
RemoteIterator<Path> it = fc.listCorruptFileBlocks(path); // non-HDFS -> UOE

// after
if (fc.hasPathCapability(path,
        CommonPathCapabilities.FS_LIST_CORRUPT_FILE_BLOCKS)) {
  RemoteIterator<Path> it = fc.listCorruptFileBlocks(path);
}
Defensive patterns

Strategy: validation

Validate before calling

if (fc.hasPathCapability(path,
        CommonPathCapabilities.FS_LIST_CORRUPT_FILE_BLOCKS)) {
  RemoteIterator<Path> it = fc.listCorruptFileBlocks(path);
}

Type guard

boolean isHdfsScheme(Path p) {
  String s = p.toUri().getScheme();
  return s == null ? "hdfs".equals(conf.get("fs.defaultFS", "").split(":")[0]) : "hdfs".equals(s);
}

Try / catch

try { fc.listCorruptFileBlocks(path); } catch (UnsupportedOperationException e) { /* corrupt-block tracking is HDFS-only: skip check */ }

Prevention

When it happens

Trigger: fc.listCorruptFileBlocks(path) on file://, s3a://, or any non-HDFS scheme; HDFS health-check utilities executed against the local filesystem in unit tests; dashboards parameterized over fs.defaultFS that probe corrupt blocks generically.

Common situations: Cluster health tooling written against HDFS run against other stores; test suites exercising admin code paths on LocalFs; code copied from DistributedFileSystem-based fsck implementations.

Related errors


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