bazelbuild/bazel · error

Could not seek to end of file (%s)

Error message

Could not seek to end of file (%s)

What it means

While restarting a Bazel server on Windows, the client opens the previous server's jvm.out log with OPEN_ALWAYS for append; if SetFilePointerEx(handle, {}, nullptr, FILE_END) fails it prints this message and returns INVALID_HANDLE_VALUE, so the new server's log file cannot be set up. It means Windows refused to seek to end-of-file on a handle that was successfully opened for read/write.

Source

Thrown at src/main/cpp/blaze_util_windows.cc:583

  // If the previous server process was asked to be shut down (but not killed),
  // it takes a while for it to comply, so wait until the JVM output file that
  // it held open is closed. There seems to be no better way to wait for a file
  // to be closed on Windows.
  static const unsigned int timeout_sec = 60;
  for (unsigned int waited = 0; waited < timeout_sec; ++waited) {
    HANDLE handle = ::CreateFileW(
        /* lpFileName */ path.AsNativePath().c_str(),
        /* dwDesiredAccess */ GENERIC_READ | GENERIC_WRITE,
        /* dwShareMode */ FILE_SHARE_READ,
        /* lpSecurityAttributes */ sa,
        /* dwCreationDisposition */
        daemon_out_append ? OPEN_ALWAYS : CREATE_ALWAYS,
        /* dwFlagsAndAttributes */ FILE_ATTRIBUTE_NORMAL,
        /* hTemplateFile */ nullptr);
    if (handle != INVALID_HANDLE_VALUE) {
      if (daemon_out_append &&
          !SetFilePointerEx(handle, {}, nullptr, FILE_END)) {
        fprintf(stderr, "Could not seek to end of file (%s)\n",
                path.AsPrintablePath().c_str());
        return INVALID_HANDLE_VALUE;
      }
      return handle;
    }
    if (GetLastError() != ERROR_SHARING_VIOLATION &&
        GetLastError() != ERROR_LOCK_VIOLATION) {
      // Some other error occurred than the file being open; bail out.
      break;
    }

    // The file is still held open, the server is shutting down. There's a
    // chance that another process holds it open, we don't know; in that case
    // we just exit after the timeout expires.
    if (waited == 5 || waited == 10 || waited == 30) {
      fprintf(stderr,
              "Waiting for previous Bazel server's log file to close "
              "(waited %d seconds, waiting at most %d)\n",

View on GitHub (pinned to e6e199d060)

Solutions

1. Run 'bazel shutdown' and wait a few seconds before the next command.
2. If it persists, stop all bazel processes (taskkill /IM bazel.exe /F and the java server) and retry.
3. Move the output base off network/synced storage: bazel --output_base=C:/_bazel_user/... or exclude it from sync/AV scanning.
4. As a last resort delete output_base/server/jvm.out while no server runs so a fresh log is created with CREATE_ALWAYS.
5. Check the Windows Application event log for filesystem/driver errors on the volume holding the output base.

Example fix

# before: rapid restart loop hits the message
bazel shutdown
timeout /t 5
bazel build //pkg
# persistent case: fresh log file
taskkill /IM bazel.exe /F 2>nul
del %OUTPUT_BASE%\server\jvm.out
bazel build //pkg

When it happens

Trigger: Starting Bazel with the same output_base while the old server is shutting down and jvm.out is still held with an incompatible sharing mode; the file being replaced/locked by backup or antivirus software between CreateFileW and the seek; handle opened on a device or redirected filesystem (network drive) that does not support seeking.

Common situations: Rapidly restarting Bazel on Windows (Ctrl-C then immediate rerun); jvm.out on a synced/network share; third-party file filters holding the log; a previous crash leaving the log handle in an odd state.

Related errors

• Waiting for previous Bazel server's log file to close (waite
• Cannot write PID file %s
• prefix msg "\n"
• Failed to make absolute path for %s: %s\n
• Expected 3 arguments, got %d\n

AI-assisted analysis of bazelbuild/bazel@e6e199d060 (2026-08-14). Data as JSON: /api/errors/1c7e51181dc7c602. Report an issue: GitHub.