eclipse-vertx/vert.x · error · FileSystemException

Cannot truncate file ${path}. Does not exist

Error message

Cannot truncate file ${path}. Does not exist

What it means

The truncate action checks Files.exists on the resolved absolute path and throws FileSystemException 'Cannot truncate file <path>. Does not exist' when the file is absent. Vert.x refuses to create/implicitly touch a file through truncate; the target must already exist. The path in the message is the resolved absolute path after FileResolver processing.

Source

Thrown at vertx-core/src/main/java/io/vertx/core/file/impl/FileSystemImpl.java:504

        } catch (IOException e) {
          throw new FileSystemException(getFileMoveErrorMessage(from, to), e);
        }
        return null;
      }
    };
  }

  private BlockingAction<Void> truncateInternal(String p, long len) {
    Objects.requireNonNull(p);
    return new BlockingAction<Void>() {
      public Void perform() {
        try {
          String path = resolveFile(p).getAbsolutePath();
          if (len < 0) {
            throw new FileSystemException("Cannot truncate file to size < 0");
          }
          if (!Files.exists(Paths.get(path))) {
            throw new FileSystemException("Cannot truncate file " + path + ". Does not exist");
          }
          try (RandomAccessFile raf = new RandomAccessFile(path, "rw")) {
            raf.setLength(len);
          }
        } catch (IOException e) {
          throw new FileSystemException(getFileAccessErrorMessage("truncate", p) ,e);
        }
        return null;
      }
    };
  }

  private BlockingAction<Void> chmodInternal(String path, String perms) {
    return chmodInternal(path, perms, null);
  }

  protected BlockingAction<Void> chmodInternal(String path, String perms, String dirPerms) {
    Objects.requireNonNull(path);

View on GitHub (pinned to fb308bd8c3)

Solutions

  1. Check fs.exists(path) and create the file first (fs.createFile) if absence is legitimate.
  2. Log/print the resolved absolute path from the message and verify it matches expectations — fix relative-path assumptions.
  3. Re-check the flow that deletes/renames the file concurrently and serialize those operations.
  4. If truncation is optional, treat 'does not exist' as a no-op instead of an error in your caller code.

Example fix

// before
vertx.fileSystem().truncateBlocking("logs/app.log", 0);
// after
FileSystem fs = vertx.fileSystem();
if (fs.existsBlocking("logs/app.log")) {
  fs.truncateBlocking("logs/app.log", 0);
} else {
  fs.createFileBlocking("logs/app.log");
}
Defensive patterns

Strategy: validation

Validate before calling

FileSystem fs = vertx.fileSystem();
String abs = Paths.get(path).toAbsolutePath().toString();
if (!fs.existsBlocking(path)) {
  fs.createFileBlocking(path); // or skip truncation
}
fs.truncateBlocking(path, len);

Type guard

static boolean truncatable(FileSystem fs, String path) {
  return fs.existsBlocking(path) && fs.propsBlocking(path).isFile();
}

Try / catch

try {
  fs.truncateBlocking(path, len);
} catch (FileSystemException e) {
  if (e.getMessage().endsWith("Does not exist")) {
    fs.createFileBlocking(path);
    fs.truncateBlocking(path, len);
  } else throw e;
}

Prevention

When it happens

Trigger: vertx.fileSystem().truncate(path, len) on a path that was never created or was deleted/renamed before the call; also when a fat-jar classpath-relative path resolves to a location that doesn't exist on the real filesystem.

Common situations: Truncating a rotating log file that was renamed by a log rotation; race with another process deleting the file; typo'd or wrong working-directory-relative path when running from a jar; file created lazily later than the truncate call.

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


AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06). Data as JSON: /api/errors/17d1a3c0ee99ed05. Report an issue: GitHub.