apache/seatunnel · warning

File checksum is not available, fallback to content comparis

Error message

File checksum is not available, fallback to content comparison. source={}, target={}

What it means

This WARN is logged once (guarded by checksumUnavailableWarned) by warnChecksumUnavailableOnce when the filesystem/file API provides no checksum for the source or target file, so the enumerator cannot use a cheap checksum-based equality check and instead falls back to a byte-by-byte content comparison. It is informational about degraded (more expensive) comparison, not a failure.

Source

Thrown at seatunnel-connectors-v2/connector-file/connector-file-base/src/main/java/org/apache/seatunnel/connectors/seatunnel/file/source/split/ContinuousMultipleTableFileSourceSplitEnumerator.java:1956

            String targetPath = config.get(FileBaseSourceOptions.TARGET_PATH);
            return buildTargetFilePath(targetPath, relativePath);
        }

        private boolean fileContentEquals(String sourceFilePath, String targetFilePath)
                throws IOException {
            try (InputStream sourceIn = sourceFs.getInputStream(sourceFilePath);
                    InputStream targetIn = targetFs.getInputStream(targetFilePath)) {
                return IOUtils.contentEquals(sourceIn, targetIn);
            }
        }

        private void warnChecksumUnavailableOnce(
                String sourceFilePath, String targetFilePath, Exception checksumException) {
            if (checksumUnavailableWarned) {
                return;
            }
            if (checksumException == null) {
                log.warn(
                        "File checksum is not available, fallback to content comparison. source={}, target={}",
                        maskUriUserInfo(sourceFilePath),
                        maskUriUserInfo(targetFilePath));
            } else {
                log.warn(
                        "File checksum is not available, fallback to content comparison. source={}, target={}",
                        maskUriUserInfo(sourceFilePath),
                        maskUriUserInfo(targetFilePath),
                        checksumException);
            }
            checksumUnavailableWarned = true;
        }

        private boolean filterByPattern(FileStatus fileStatus) {
            if (pattern == null || fileBasePath == null) {
                return true;
            }
            if (pattern.pattern().startsWith(fileBasePath)) {

View on GitHub (pinned to cf67b549a7)

Solutions

  1. No action strictly required — the sync continues correctly with content comparison.
  2. If performance matters, store files on a filesystem that exposes checksums (e.g. HDFS with checksums enabled) so equality checks stay cheap.
  3. Expect this WARN only once per enumerator lifecycle; if it recurs the enumator was likely restarted (new instance).
Defensive patterns

Strategy: validation

Validate before calling

// Check checksum support before enabling checksum-based sync
FileChecksum ck = fs.getFileChecksum(path);
boolean checksumSupported = ck != null;

Prevention

When it happens

Trigger: First time a file pair is compared in a sync cycle where obtaining a file checksum returns null/unavailable for the storage backend — e.g. object stores (S3/OSS) or local filesystems that do not expose checksums through the Hadoop FileSystem API used here.

Common situations: Using S3, OSS, or local FS targets that don't return checksums; HDFS erasure-coded or encrypted zones without checksum support; comparing files across heterogeneous filesystems where one side lacks checksum support.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/edaba1fbe371e654. Report an issue: GitHub.