apache/hadoop · error · IOException

Mark not supported

Error message

Mark not supported

What it means

FTPInputStream.markSupported() returns false and mark() is deliberately a no-op, so reset() always throws IOException("Mark not supported") — over a sequential FTP data stream there is no buffered position to rewind to.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ftp/FTPInputStream.java:137

          + client.getReplyCode());
    }
  }

  // Not supported.

  @Override
  public boolean markSupported() {
    return false;
  }

  @Override
  public void mark(int readLimit) {
    // Do nothing
  }

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

View on GitHub (pinned to 2add963021)

Solutions

  1. Wrap in a BufferedInputStream sized for the parser's lookahead and mark/reset only through the wrapper
  2. Check markSupported() before mark/reset and fail with a clear message otherwise
  3. Buffer the whole payload (read into byte[]) when small and random re-reads are needed
  4. Best: copy to local/HDFS and parse from there

Example fix

// before
try (FSDataInputStream in = fs.open(path)) {
  in.mark(1 << 16);
  parseSome(in);
  in.reset();               // IOException: Mark not supported
}

// after
try (BufferedInputStream in = new BufferedInputStream(fs.open(path), 1 << 16)) {
  if (!in.markSupported()) { throw new IllegalStateException("need mark/reset"); }
  in.mark(1 << 16);
  parseSome(in);
  in.reset();               // served from the buffer
}
Defensive patterns

Strategy: validation

Validate before calling

InputStream toParse = fs.open(path);
if (!toParse.markSupported()) {
  toParse = new BufferedInputStream(toParse, 1 << 16);  // provide mark/reset via buffering
}
// safe: markSupported() is now guaranteed true before any mark/reset

Prevention

When it happens

Trigger: Wrapping code that marks/resets: java.util.Scanner over the raw stream, pull parsers that backtrack, or application code calling mark() then reset() and not noticing mark() silently did nothing.

Common situations: Passing the raw FTP stream to parsers requiring mark/reset; generic utilities that ignore markSupported(); porting local-file parsing code to ftp:// paths.

Related errors


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