alibaba/nacos · error · FileNotFoundException

{getDescription()} cannot be resolved in the file system for

Error message

{getDescription()} cannot be resolved in the file system for checking its last-modified timestamp

What it means

Thrown by the default AbstractResource.lastModified() (the AbstractResource version, distinct from AbstractFileResolvingResource) when getFileForLastModifiedCheck() returns a File whose lastModified() is 0 and which does not exist. FileNotFoundException indicates the resource could not be resolved to an existing file for timestamp checking.

Source

Thrown at common/src/main/java/com/alibaba/nacos/common/packagescan/resource/AbstractResource.java:191

                if (logger.isDebugEnabled()) {
                    logger.debug("Could not close content-length InputStream for " + getDescription(), ex);
                }
            }
        }
    }

    /**
     * This implementation checks the timestamp of the underlying File,
     * if available.
     *
     * @see #getFileForLastModifiedCheck()
     */
    @Override
    public long lastModified() throws IOException {
        File fileToCheck = getFileForLastModifiedCheck();
        long lastModified = fileToCheck.lastModified();
        if (lastModified == 0L && !fileToCheck.exists()) {
            throw new FileNotFoundException(getDescription()
                    + " cannot be resolved in the file system for checking its last-modified timestamp");
        }
        return lastModified;
    }

    /**
     * Determine the File to use for timestamp checking.
     * The default implementation delegates to {@link #getFile()}.
     *
     * @return the File to use for timestamp checking (never {@code null})
     * @throws FileNotFoundException if the resource cannot be resolved as
     *                               an absolute file path, i.e. is not available in a file system
     * @throws IOException           in case of general resolution/reading failures
     */
    protected File getFileForLastModifiedCheck() throws IOException {
        return getFile();
    }

View on GitHub (pinned to 9b989acdf1)

Solutions

  1. Check the file exists (file.exists()) before calling lastModified().
  2. Override getFileForLastModifiedCheck() in your subclass to return a real, existing File, or rely on a URL-based timestamp.
  3. Catch FileNotFoundException and treat timestamp as unknown rather than fatal.
  4. Use AbstractFileResolvingResource (URL-connection fallback) instead of bare AbstractResource if the resource may not be file-backed.

Example fix

// before
long ts = resource.lastModified(); // throws if file missing

// after
File f = resource.getFileForLastModifiedCheck();
long ts = f.exists() ? f.lastModified() : -1L;
Defensive patterns

Strategy: validation

Validate before calling

File f = resource.getFileForLastModifiedCheck();
if (!f.exists()) {
    return -1L;
}
return resource.lastModified();

Type guard

boolean hasFileTimestamp(Resource r) {
    try { return r.getFileForLastModifiedCheck().exists(); }
    catch (IOException e) { return false; }
}

Try / catch

try {
    long ts = resource.lastModified();
} catch (FileNotFoundException e) {
    log.debug("No file for timestamp: {}", e.getMessage());
    ts = -1L;
}

Prevention

When it happens

Trigger: Calling lastModified() on an AbstractResource subclass where getFileForLastModifiedCheck() (defaulting to getFile()) returns a non-existent path; resource that has no file representation so getFile() yields a phantom path.

Common situations: A resource subclass whose getFile() returns a path inside a jar or a deleted file; stale resource handle after the underlying file was removed; subclass that overrode getFileForLastModifiedCheck() to return a wrong path.

Related errors


AI-assisted analysis of alibaba/nacos@9b989acdf1 (2026-08-14). Data as JSON: /api/errors/52ea33e5d8dd946f. Report an issue: GitHub.