apache/hadoop · error · RuntimeException

Failed to rename %s to %s

Error message

Failed to rename %s to %s

What it means

FileStore.rename implements ObjectStorage.rename with java.io.File.renameTo(src, dst). That JVM method returns false instead of throwing on failure (cross-filesystem rename, missing destination parent, permission denied, destination locked by an open handle on Windows), and the connector converts the false into RuntimeException("Failed to rename <srcKey> to <dstKey>").

Source

Thrown at hadoop-cloud-storage-project/hadoop-tos/src/main/java/org/apache/hadoop/fs/tosfs/object/FileStore.java:578

    File file = path(encode(srcKey)).toFile();
    if (!file.exists()) {
      throw new RuntimeException(String.format("File not found %s", file.getAbsolutePath()));
    }

    put(dstKey, () -> get(srcKey).stream(), file.length());
  }

  @Override
  public void rename(String srcKey, String dstKey) {
    Preconditions.checkArgument(!Objects.equals(srcKey, dstKey),
        "Cannot rename to the same object");
    Preconditions.checkNotNull(head(srcKey), "Source key %s doesn't exist", srcKey);

    File srcFile = path(encode(srcKey)).toFile();
    File dstFile = path(encode(dstKey)).toFile();
    boolean ret = srcFile.renameTo(dstFile);
    if (!ret) {
      throw new RuntimeException(String.format("Failed to rename %s to %s", srcKey, dstKey));
    }
  }

  @Override
  public ObjectInfo objectStatus(String key) {
    ObjectInfo obj = head(key);
    if (obj == null && !ObjectInfo.isDir(key)) {
      key = key + '/';
      obj = head(key);
    }

    if (obj == null) {
      Iterable<ObjectInfo> objs = list(key, null, 1);
      if (objs.iterator().hasNext()) {
        obj = new ObjectInfo(key, 0, new Date(0), Constants.MAGIC_CHECKSUM);
      }
    }

View on GitHub (pinned to 2add963021)

Solutions

1. Ensure both keys live on the same filesystem/volume under the store root
2. Create the destination parent directory before renaming
3. Check OS write permissions on both parent directories
4. Fall back to copy(srcKey, dstKey) followed by delete(srcKey) when renameTo keeps failing
5. Close any open streams referencing src or dst before renaming (mainly Windows)

Example fix

// before
storage.rename(srcKey, dstKey);

// after: portable copy+delete fallback
try {
  storage.rename(srcKey, dstKey);
} catch (RuntimeException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Failed to rename")) {
    storage.copy(srcKey, dstKey);
    storage.delete(srcKey);
  } else {
    throw e;
  }
}

// ensure destination parent exists before renaming
java.nio.file.Path dst = storeRoot.resolve(encode(dstKey));
java.nio.file.Path parent = dst.getParent();
if (parent != null && !java.nio.file.Files.exists(parent)) {
  java.nio.file.Files.createDirectories(parent);
}

try {
  storage.rename(srcKey, dstKey);
} catch (RuntimeException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Failed to rename")) {
    storage.copy(srcKey, dstKey);
    storage.delete(srcKey);
  } else {
    throw e;
  }
}

When it happens

Trigger: Renaming between keys that resolve to different mount points/devices under the store root; the destination parent directory not existing; no write/execute permission on the target directory; destination or source file held open (mainly Windows); the source removed by a concurrent process between checkNotNull and renameTo.

Common situations: Store root spanning multiple filesystems or symlinked to another volume; running as a user without write permission on the directory; Windows dev/test boxes with open file handles; concurrent jobs renaming the same key.

Related errors

• {} is root directory
• Expected checksum is %s while actual checksum is %s
• Cannot seek to a negative offset %s
• position is negative
• Stream is closed!

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