apache/hadoop · error · IOException

dump not supported

Error message

dump not supported

What it means

CosNativeFileSystemStore implements the NativeFileSystemStore contract, whose dump() operation is a debugging hook that lists the store's contents. The COS (Tencent Cloud) implementation deliberately does not support it, so calling dump() always throws an immediate IOException("dump not supported") before any network call is made. The sibling purge(prefix) method is likewise a permanent UnsupportedOperationException-style stub. This mirrors the pattern inherited from the s3a store interface this connector was modeled on.

Source

Thrown at hadoop-cloud-storage-project/hadoop-cos/src/main/java/org/apache/hadoop/fs/cosn/CosNativeFileSystemStore.java:652

    } catch (Exception e) {
      String errMsg = String.format("Copy object unsuccessfully. "
              + "source COS key: %s, dest COS key: " +
              "%s, exception: %s",
          srcKey,
          dstKey, e.toString());
      LOG.error(errMsg);
      handleException(new Exception(errMsg), srcKey);
    }
  }

  @Override
  public void purge(String prefix) throws IOException {
    throw new IOException("purge not supported");
  }

  @Override
  public void dump() throws IOException {
    throw new IOException("dump not supported");
  }

  // process Exception and print detail
  private void handleException(Exception e, String key) throws IOException {
    String cosPath = CosNFileSystem.SCHEME + "://" + bucketName + key;
    String exceptInfo = String.format("%s : %s", cosPath, e.toString());
    throw new IOException(exceptInfo);
  }

  @Override
  public long getFileLength(String key) throws IOException {
    LOG.debug("Get file length. COS key: {}", key);
    GetObjectMetadataRequest getObjectMetadataRequest =
        new GetObjectMetadataRequest(bucketName, key);
    try {
      ObjectMetadata objectMetadata =
          (ObjectMetadata) callCOSClientWithRetry(getObjectMetadataRequest);
      return objectMetadata.getContentLength();

View on GitHub (pinned to 2add963021)

Solutions

1. Skip or gate the dump() call when the scheme is cosn (it is a diagnostic-only API, no data path depends on it)
2. If you ported s3a tests, delete/ignore the dump and purge test cases for the cosn store
3. If you genuinely need a bucket listing, call listObjects/listStatus on the filesystem instead of dump()
4. As a last resort, subclass CosNativeFileSystemStore and implement dump() by iterating a COS listObjects request

Example fix

// before
store.dump(); // throws IOException("dump not supported") on cosn

// after
if ("cosn".equals(fs.getUri().getScheme())) {
  LOG.warn("dump() is not supported by the cosn store; skipping");
} else {
  store.dump();
}

// Only invoke dump()/purge() on stores that support them
if (store instanceof CosNativeFileSystemStore) {
  LOG.warn("dump()/purge() unsupported by cosn store; skipping diagnostic");
} else {
  store.dump();
}

When it happens

Trigger: Calling store.dump() (or purge()) directly on a CosNativeFileSystemStore instance. Typically reached from filesystem sanity-check tooling, ops scripts, or unit tests ported from hadoop-aws's s3a NativeFileSystemStore tests, which exercise dump()/purge() as part of the store contract.

Common situations: Porting test suites from hadoop-aws s3a to hadoop-cos without pruning dump/purge cases; running a generic cloud-store diagnostic tool that assumes every NativeFileSystemStore can dump its keys; upgrading to a hadoop-cos version where the store interface gained these methods.

Related errors

• %s : %s
• no such method
• Call cos sdk failed, call method: %s, exception: %s
• No COS Credential Providers
• Credentials requested after provider list was closed

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