"Unexpected" error building project with dependencies

[pvande]

Zig Version

0.14.0

Steps to Reproduce and Observed Behavior

Preconditions:

• macOS 15
• project/build.zig.zon, which points to project/child/build.zig.zon by .path
• project/child/build.zig.zon, which points to additional dependencies by .url

Run:

• zig build

Result:

error: unable to rename temporary directory '/Users/username/.cache/zig/tmp/a76822d382aec5fc' into package cache directory '/Users/username/.cache/zig/p/N-V-__8AAKmsPQrl1anK5hm8jzXt1sWUly2hH5fCdP1IiAau': Unexpected

(Running mv ${source} ${dest} in the terminal succeeds without issue.)

Expected Behavior

I ideally would expect Zig to build the project successfully, or not fail a simple rename, or to at least provide an actionable error.

[squeek502]

Likely a duplicate of #17342

If so, then iCloud syncing is interfering with filesystem operations. Some potential workarounds are mentioned in #17342 (comment) and later comments.

[pvande]

It didn't seem likely that this was related to that ticket in particular — I've had this issue on two separate machines, including a VM without an associated Apple account, and neither of which had done anything to enable any non-default backup behaviors.

I did go to the extent of building a Stage 2 Zig compiler, in order to try and produce some better debugging tools, with the result being this:

zig build
thread 350745 panic: reached unreachable code
/Users/username/Projects/zig/lib/std/posix.zig:2752:19: 0x10899aa4f in renameatZ (zig)
        .INVAL => unreachable,
                  ^
/Users/username/Projects/zig/lib/std/posix.zig:2686:25: 0x1088582a3 in renameat (zig)
        return renameatZ(old_dir_fd, &old_path_c, new_dir_fd, &new_path_c);
                        ^
/Users/username/Projects/zig/lib/std/fs/Dir.zig:1748:26: 0x1088c9e47 in rename (zig)
    return posix.renameat(self.fd, old_sub_path, self.fd, new_sub_path);
                         ^
/Users/username/Projects/zig/src/Package/Fetch.zig:1426:25: 0x108900253 in renameTmpIntoCache (zig)
        cache_dir.rename(tmp_dir_sub_path, dest_dir_sub_path) catch |err| switch (err) {
                        ^
/Users/username/Projects/zig/src/Package/Fetch.zig:540:23: 0x108a1f5bf in runResource (zig)
    renameTmpIntoCache(cache_root.handle, package_sub_path, f.package_root.sub_path) catch |err| {
                      ^
/Users/username/Projects/zig/src/Package/Fetch.zig:445:25: 0x10891802b in run (zig)
    return f.runResource(try uri.path.toRawMaybeAlloc(arena), &resource, remote.hash);
                        ^
/Users/username/Projects/zig/src/Package/Fetch.zig:801:8: 0x108a08aa3 in workerRun (zig)
    run(f) catch |err| switch (err) {
       ^
/Users/username/Projects/zig/lib/std/Thread/Pool.zig:119:39: 0x108f2de7b in runFn (zig)
            @call(.auto, func, closure.arguments);
                                      ^
/Users/username/Projects/zig/lib/std/Thread/Pool.zig:295:32: 0x108c2c6c3 in worker (zig)
            run_node.data.runFn(&run_node.data, id);
                               ^
/Users/username/Projects/zig/lib/std/Thread.zig:488:13: 0x108a89657 in callFn__anon_190214 (zig)
            @call(.auto, f, args);
            ^
/Users/username/Projects/zig/lib/std/Thread.zig:757:30: 0x1089568c3 in entryFn (zig)
                return callFn(f, args_ptr.*);
                             ^
???:?:?: 0x1983182e3 in ??? (libsystem_pthread.dylib)
???:?:?: 0x1983130fb in ??? (libsystem_pthread.dylib)

According to the manpage:

     [EINVAL]           Old is a parent directory of new, or an attempt is made to rename ‘.’ or ‘..’.  If RENAME_SWAP is used, then EINVAL will also be returned if new is
                        a parent directory of old.  If both RENAME_SWAP and RENAME_EXCL bits are set in flags, then EINVAL will be returned.

     [EINVAL]           flags has an invalid value.

---

If there's anything more I can do to help debug this problem, please let me know. I had previously been able to work around this by manually moving the directory, but that no longer seems to be a viable option as of 0.14.0.

[rootbeer]

As a work-around, you might try setting the ZIG_LOCAL_CACHE_DIR and ZIG_GLOBAL_CACHE_DIR environment variables (or the equivalent command-line options) to point to a /tmp or other directory that might be "simpler" than /Users/username/.cache/. If that does work, it would be nice to know if there is something about the original directory that may be creating the conflicts...

[pvande]

@rootbeer Running with fully local values (e.g. ZIG_GLOBAL_CACHE_DIR=.zig-global) and fully external values (e.g. ZIG_GLOBAL_CACHE_DIR=/tmp/.zig-global) both fail in exactly the same way.

[rootbeer]

One more stab in the dark here ... over in #23110 there is some suggestion that a corrupted cache can trigger subsequent, persistent problems with cache files. So if you haven't tried rm -rfing your cache(s) to see if things improve, you might try that? Your problem feels different enough (the EINVAL), though, that this seems unlikely.

Can you share more details about the project you're building? If its not public, have you had any luck making a minimal repro?

Is this project one you're building just once and it fails, or are you doing active development in it, and it eventually gets stuck?

[pvande]

@rootbeer I've definitely blown the cache files away multiple times (and, in the case of the *_CACHE_DIR variables, pointed the cache to empty space), without success.

The project in question is private, but a good chunk of it is just building public C/++ libraries. The failures have happened pretty consistently since I first put together the build scripts, but I could previously (0.14.0-dev.2319+1a99c99eework around it by manually moving the files. I haven't had a lot of success producing a more minimal reproduction case, but I may find myself moving that direction soon.

For what it's worth, the project is broadly structured like this:

- project/
  - build.zig
  - build.zig.zon
    - Dependency: tracy (path: ./tracy/)
    - Dependency: frida (url: ….tar.xz)
   
  - tracy/
    - build.zig
    - build.zig.zon
      - Dependency: tracy (url: ….tar.gz)
      - Dependency: capstone (url: ….tar.gz)
      - Dependency: ppqsort (url: ….tar.gz)
      - Dependency: freetype (url: ….tar.gz)
      - Dependency: imgui (url: ….tar.gz)
      - Dependency: zglfw (url: ….tar.gz)

---

After verifying that it wasn't the obvious dependency name conflict (conclusion: it wasn't), I checked the next most obvious thing, which is that the frida dependency is a tar.xz archive. Swapping the tar.xz URL for an unrelated tar.gz URL allowed the build to advance.