apache/hadoop · error · FileNotFoundException

"File/Directory " + iip.getPath() + " does not exist."

Error message

"File/Directory " + iip.getPath() + " does not exist."

What it means

Thrown by the NameNode while processing setTimes (ClientProtocol.setTimes) when the resolved path's last component has no inode, i.e. the file or directory does not exist in the namespace. unprotectedSetTimes resolves the path with INodesInPath and treats a null last inode as a hard failure. Because resolution and the metadata update happen under the write lock, in practice this almost always means the path was deleted or renamed before the RPC landed, or the client is using a stale path.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirAttrOp.java:500

      List<XAttr> removed = Lists.newArrayList();
      newXAttrs = FSDirXAttrOp.filterINodeXAttrs(existingXAttrs, toRemove,
          removed);
    } else {
      newXAttrs = FSDirXAttrOp.setINodeXAttrs(fsd, existingXAttrs,
          Arrays.asList(xAttr),
          EnumSet.of(XAttrSetFlag.CREATE, XAttrSetFlag.REPLACE));
    }
    XAttrStorage.updateINodeXAttrs(inode, newXAttrs, iip.getLatestSnapshotId());
  }

  static boolean unprotectedSetTimes(
      FSDirectory fsd, INodesInPath iip, long mtime, long atime, boolean force)
      throws FileNotFoundException {
    assert fsd.hasWriteLock();
    boolean status = false;
    INode inode = iip.getLastINode();
    if (inode == null) {
      throw new FileNotFoundException("File/Directory " + iip.getPath() +
          " does not exist.");
    }
    int latest = iip.getLatestSnapshotId();
    if (mtime >= 0) {
      inode = inode.setModificationTime(mtime, latest);
      status = true;
    }

    // if the last access time update was within the last precision interval,
    // then no need to store access time
    if (atime >= 0 && (status || force
        || atime > inode.getAccessTime() + fsd.getAccessTimePrecision())) {
      inode.setAccessTime(atime, latest,
          fsd.getFSNamesystem().getSnapshotManager().
          getSkipCaptureAccessTimeOnlyChange());
      status = true;
    }
    return status;

View on GitHub (pinned to 2add963021)

Solutions

1. Verify the path exists immediately before the call with fs.getFileStatus(path) and treat a FileNotFoundException from that check as 'skip'.
2. If a concurrent delete is expected, catch FileNotFoundException around setTimes and re-check existence to distinguish 'deleted meanwhile' (ignore) from a real bug (fix the path).
3. Audit the code path that produced the path string — usually a stale listing, a wrong base directory, or a path built for the wrong cluster/namespace.
4. For distcp-like metadata sync, snapshot or lock the source set so delete/rename cannot interleave with setTimes.

Example fix

// before
fs.setTimes(path, mtime, atime);

// after
try {
  fs.setTimes(path, mtime, atime);
} catch (FileNotFoundException e) {
  // removed by a concurrent delete/rename; verify and skip
  if (!fs.exists(path)) {
    LOG.debug("Skipping setTimes, path deleted concurrently: {}", path);
  } else {
    throw e;
  }
}

// shrink the race window; does not eliminate it
if (!fs.exists(path)) {
  return; // nothing to update
}

try {
  fs.setTimes(path, mtime, atime);
} catch (FileNotFoundException e) {
  // deleted/renamed concurrently: confirm and skip
  if (!fs.exists(path)) { LOG.debug("setTimes skipped, path gone: {}", path); }
  else { throw e; }
}

When it happens

Trigger: Calling DistributedFileSystem.setTimes(path, mtime, atime) (or any API that funnels into FSDirAttrOp.setTimes, e.g. distcp preserving times) on a path that (a) never existed due to a typo, (b) was deleted between the client's listing and the setTimes call, or (c) was renamed concurrently.

Common situations: Distcp or archive jobs copying metadata for files that another process is deleting; retrying operations against a path after a failover where the edit was lost; tools that cache FileStatus objects and later call setTimes on them.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

• File is deleted: {} (inode {}) {}
• File not found: {}, likely due to delayed block removal
• Path {} does not exist
• Directory does not exist: {}
• File does not exist: {}

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