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
- Wrap in a BufferedInputStream sized for the parser's lookahead and mark/reset only through the wrapper
- Check markSupported() before mark/reset and fail with a clear message otherwise
- Buffer the whole payload (read into byte[]) when small and random re-reads are needed
- 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
- Check markSupported() before mark/reset on any wrapped stream
- Feed parsers a BufferedInputStream, never the raw FTP stream
- For small files, read fully into memory and parse from the byte array
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
- Seek not supported
- Cannot rename source: {absoluteSrc} to {absoluteDst} -only s
- Stream closed
- Not a ByteBufferPositionedReadable: ${in}
- mark()/reset() not supported on this stream
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/c5cd1bffe0c7e471.
Report an issue: GitHub.