apache/hadoop · error · UnsupportedFileSystemException

getFileChecksum(Path, long) is not supported by

Error message

getFileChecksum(Path, long) is not supported by 

What it means

getFileChecksum(Path, long) with a length argument uses HDFS-specific combined-mode checksums (dfs.getFileChecksumWithCombineMode). When a symlink resolves onto a filesystem that is not a DistributedFileSystem, the generic FileSystem contract cannot express this operation, so the resolver throws UnsupportedFileSystemException naming the target filesystem class.

Solutions

  1. Resolve the link target yourself and only call getFileChecksum(p, length) on the DistributedFileSystem that owns the target.
  2. Use the single-argument getFileChecksum(p), which is part of the generic FileSystem API and works cross-filesystem via fallback.
  3. Restructure so checksum verification never traverses cross-filesystem symlinks.
  4. Skip/flag foreign-scheme paths in verification jobs instead of failing the whole run.

Example fix

// before
FileChecksum cs = hdfs.getFileChecksum(linkPath, length); // UnsupportedFileSystemException

// after
Path target = hdfs.getLinkTarget(linkPath);
FileSystem targetFs = FileSystem.get(target.toUri(), conf);
FileChecksum cs = targetFs instanceof DistributedFileSystem
    ? targetFs.getFileChecksum(target, length)
    : targetFs.getFileChecksum(target);
Defensive patterns

Strategy: fallback

Validate before calling

Path target = fs.getLinkTarget(p);
FileSystem tfs = FileSystem.get(target.toUri(), conf);
if (!(tfs instanceof DistributedFileSystem)) {
  // plan to use single-arg getFileChecksum on tfs instead
}

Try / catch

try {
  cs = fs.getFileChecksum(p, length);
} catch (UnsupportedFileSystemException e) {
  cs = fs.getFileChecksum(p); // generic API works cross-filesystem
}

Prevention

When it happens

Trigger: Calling fs.getFileChecksum(p, length) where p is an HDFS symlink whose target resolves onto a non-HDFS filesystem (file://, s3a://, etc.), so next(fs, p) receives a foreign FileSystem instance.

Common situations: Data-integrity tools computing partial checksums over hybrid lakes with cross-scheme symlinks; checksum verification code that worked on plain HDFS paths after symlinks were introduced by a re-layout; mount-table (viewfs) setups routing some paths to object stores.

Related errors


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

Appendix: source

Thrown at hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java:2085

  @Override
  public FileChecksum getFileChecksum(Path f, final long length)
      throws IOException {
    statistics.incrementReadOps(1);
    storageStatistics.incrementOpCounter(OpType.GET_FILE_CHECKSUM);
    Path absF = fixRelativePart(f);
    return new FileSystemLinkResolver<FileChecksum>() {
      @Override
      public FileChecksum doCall(final Path p) throws IOException {
        return dfs.getFileChecksumWithCombineMode(getPathName(p), length);
      }

      @Override
      public FileChecksum next(final FileSystem fs, final Path p)
          throws IOException {
        if (fs instanceof DistributedFileSystem) {
          return fs.getFileChecksum(p, length);
        } else {
          throw new UnsupportedFileSystemException(
              "getFileChecksum(Path, long) is not supported by "
                  + fs.getClass().getSimpleName());
        }
      }
    }.resolve(this, absF);
  }

  @Override
  public void setPermission(Path p, final FsPermission permission
  ) throws IOException {
    statistics.incrementWriteOps(1);
    storageStatistics.incrementOpCounter(OpType.SET_PERMISSION);
    Path absF = fixRelativePart(p);
    new FileSystemLinkResolver<Void>() {
      @Override
      public Void doCall(final Path p) throws IOException {
        dfs.setPermission(getPathName(p), permission);
        return null;

View on GitHub (pinned to 2add963021)