Bad edge case handling of concatenated dunce::simplified() paths (Windows)

[m-haug]

Description

Since updating to jj v0.28, best as I can tell, jj git init panics with a file not found error.

Steps to Reproduce the Problem

1. Run jj git init

Expected Behavior

Creating a new repository

Actual Behavior

Panic when writing operations.

Specifications

• Platform: Windows 11
• Version: 0.28.2

Output

$ env RUST_BACKTRACE=full jj --debug git init colocate
2025-04-08T08:13:31.758354Z  INFO jj_cli::cli_util: debug logging enabled
2025-04-08T08:13:31.835155Z  INFO run_command:build_index_segments_at_operation{operation=Operation { id: OperationId("00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000") }}: jj_lib::default_index::store: indexing commits reachable from historical heads maybe_parent_file=None heads_count=1
2025-04-08T08:13:31.836470Z  INFO run_command:build_index_segments_at_operation{operation=Operation { id: OperationId("00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000") }}: jj_lib::default_index::store: saved new index file index_file=ReadonlyIndexSegment { name: "d27ad326963b75736b636adad9fb812eb3f2871e0efb4bc7db37d4b701a4282911eaaee91bed3a759e940769b667be1ed66f2d7f2f41ac3906b87ab7eec19c3a", parent_file: None } commits_count=1

thread 'main' panicked at lib\src\transaction.rs:138:14:
called `Result::unwrap()` on an `Err` value: WriteObject { object_type: "operation", source: Os { code: 3, kind: NotFound, message: "Das System kann den angegebenen Pfad nicht finden." } }
stack backtrace:
   0:     0x7ff6912dec31 - git_odb_object_data
   1:     0x7ff691305eea - git_odb_object_data
   2:     0x7ff6912d8797 - git_odb_object_data
   3:     0x7ff6912dea75 - git_odb_object_data
   4:     0x7ff6912e17c0 - git_odb_object_data
   5:     0x7ff6912e15b1 - git_odb_object_data
   6:     0x7ff6912e239f - git_odb_object_data
   7:     0x7ff6912e2139 - git_odb_object_data
   8:     0x7ff6912df79f - git_odb_object_data
   9:     0x7ff6912e1d3e - git_odb_object_data
  10:     0x7ff6914633a1 - git_midx_writer_new
  11:     0x7ff6914637d0 - git_midx_writer_new
  12:     0x7ff690e23a6c - git_filter_source_repo
  13:     0x7ff690e36936 - git_filter_source_repo
  14:     0x7ff690e38ef2 - git_filter_source_repo
  15:     0x7ff690e39c6c - git_filter_source_repo
  16:     0x7ff690e37d6b - git_filter_source_repo
  17:     0x7ff6906bd472 - git_filter_source_repo
  18:     0x7ff690906304 - git_filter_source_repo
  19:     0x7ff6904911e3 - <unknown>
  20:     0x7ff69060b65b - <unknown>
  21:     0x7ff69081ca44 - git_filter_source_repo
  22:     0x7ff69040105e - <unknown>
  23:     0x7ff690401016 - <unknown>
  24:     0x7ff6912cde0c - git_odb_object_data
  25:     0x7ff69040109c - <unknown>
  26:     0x7ff691427494 - git_midx_writer_new
  27:     0x7ffe2c53e8d7 - BaseThreadInitThunk
  28:     0x7ffe2d6314fc - RtlUserThreadStart

[m-haug]

The problem seems isolated to jj git init, working with an existing repository didn't cause any problems.

[yuja]

Panicking is bad, but I have no idea why NotFound error occurred in the write path. Which one is the last working jj version? Some changes in the tempfile crate might cause a problem, but an index file appears to be written successfully.

Maybe there would be some Windows tool to trace system call?

[m-haug]

Panicking is bad, but I have no idea why NotFound error occurred in the write path.

AFAIK, that can happen when trying to write to a directory that doesn't exist.

Which one is the last working jj version?

I just went back through old scoop versions, and the problem was absent from v0.24.0, but occurs in v0.25.0.

[m-haug]

But now, v0.28.2 fails with the repository initialized by v0.24 as well.

v0.25 failing is weird because I definitely updated jj since the start of the year, so I should have had v0.25 at least.

[yuja]

AFAIK, that can happen when trying to write to a directory that doesn't exist.

Sure. I mean I have no idea why the directory didn't exist, etc.

I just went back through old scoop versions, and the problem was absent from v0.24.0, but occurs in v0.25.0.

One potential change that could affect Windows is 78b5766. If your work directory path is long, can you test with shorter path (or longer path enough to enforce the \\?\C:\ prefix)? I suspect the repository path is okay without \\?\, but the concatenated file path isn't.

[m-haug]

If your work directory path is long, can you test with shorter path (or longer path enough to enforce the \?\C:\ prefix)?

I renamed the directory to have a shorter path, and, indeed, the error went away.

[yuja]

Things like https://crates.io/crates/cap-std might help if it uses openat()-like API on Windows. We could instead keep user-facing path and canonicalized path separately, but that would be horrible.

iirc, there's a some way to extend the maximum path length by setting metadata to executable, but I don't know the detail.