Getting error about "illegal file type 'unknown'" when fetching dependencies

Help
1

I try to build the newly released Ghostty (using commit 579de8e491845b52e42d32a5dc3deaeb159ea4bc at the time of writing).

When running zig build, it starts to fetch dependencies and eventually fails with errors such as

ghostty/pkg/wuffs/build.zig.zon:6:20: error: package contains 'wuffs-0.4.0-alpha.8/test/data/hippopotamus.masked-with-muybridge.png' which has illegal file type 'unknown'
            .url = "https://github.com/google/wuffs/archive/refs/tags/v0.4.0-alpha.8.tar.gz",
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and the same for various other dependencies, for files with different endings like .h, .cc which (to me at least) are clearly not unknown.

What does this mean? Is it a problem with Ghostty’s build script and dependency declarations (I suppose not, since many people have been able to use it before), or with Zig, or with my system?

I am using the Zig 0.13.0 release version.

2

Also, it fails similarly when running zig fetch with one of the URLs. It displays Fetch, hangs for a minute or so, then there is the error.

wget with the same URL runs successfully in a few seconds, so the network connection does not seem to be the problem.

3

That error message comes from this block of code:

            const kind: HashedFile.Kind = switch (entry.kind) {
                .directory => unreachable,
                .file => .file,
                .sym_link => .link,
                else => return f.fail(f.location_tok, try eb.printString(
                    "package contains '{s}' which has illegal file type '{s}'",
                    .{ entry.path, @tagName(entry.kind) },
                )),
            };

So it’s not about the file extension - something went wrong during the unpacking and that file system entry is somehow neither a directory, nor a file, nor a symlink. It’s not even a block_device, character_device, named_pipe, unix_domain_socket, whiteout, door, or event_port.

Sounds like something has gone horribly wrong on the file system. Any ideas why that might be?

4

Okay, that’s a useful hint. I was running this in a VM where the home directory is a network storage mounted using NFS.

I think /tmp is a filesystem local to the VM. Which parts would need to be moved there, if I were to try this again later?

Currently, following parts all are inside the home directory:

  • unpacked Zig release (zig executable and lib directory)
  • working directory when running zig build
  • cloned Ghostty repository (== working directory)
5

I tried it:

  • just moving the source and working directory to /tmp does not help
  • moving the Zig executable and lib to /tmp also does not help
  • overriding HOME to point inside /tmp helps! (in fact, just doing this helps)
6

The filesystem likely doesn’t report the kind during iteration. The relevant issue is

One possible fix is here (it’s on my list of PRs to revive)

2 Likes