DiskDirectory services don't resolve absolute paths against import paths

[isker]

Reproduction steps:

1. Put this configuration in a file named app.capnp:

using Workerd = import "/workerd/workerd.capnp";

const config :Workerd.Config = (
  sockets = [
    (
      name = "directory-viewer",
      address = "*:8080",
      http = (),
      service = "dir"
    ),
  ],
  services = [
    (
      name = "dir",
      disk = (
        path = "/assets"
      )
    )
  ]
);

2. In the same directory, mkdir assets; workerd -I $(pwd) serve app.capnp

The expectation is that startup succeeds and serves from the empty directory on 8080.

Instead:

λ tree
.
├── app.capnp
└── assets

2 directories, 1 file

λ workerd serve -I $(pwd) app.capnp
Directory named "dir" not found: /assets

The comment here indicates absolute paths should work:

workerd/src/workerd/server/workerd.capnp

Lines 763 to 768 in f0b6c86

	path @0 :Text;
	# The filesystem path of the directory. If not specified, then it must be specified on the
	# command line with `--directory-path <service-name>=<path>`.
	#
	# Relative paths are interpreted relative to the current directory where the server is executed,
	# NOT relative to the config file. So, you should usually use absolute paths in the config file.

Because this doesn't work, I think workerd configurations containing DiskDirectory services can only ever be served from the single directory where the relative path in the configuration is correct, or by duplicatively passing the directory on the CLI with -d, like workerd serve -ddir=/tmp/disk-test/assets /tmp/disk-test/app.capnp.

[isker]

Maybe I'm misinterpreting the comment, and the current behavior is intentional, but it'd be strange that absolute paths in disk path don't work the same way that absolute paths do elsewhere (resolved against any directories passed to workerd serve -I [...]).

[kentonv]

This is working as intended. The path for a DiskDirectory is a simple location on disk. It's the same location that would be listed if you typed ls <path> on the command line. It is not influenced by -I flags.

The -I flags control the import path used for import and embed directives within the config file. Imports and embeds are followed entirely at startup, while loading/parsing your config. Once the server has started, all of these files have been loaded into memory and will not be reloaded from disk later. You can even use workerd compile to generate a new binary that has the config baked it, and then run that binary on a different machine where the config files aren't present.

DiskDirectory, meanwhile, dynamically serves a directory on disk. Changes to the content of that directory will immediately be reflected in an already-running workerd instance. DiskDirectory can even be writable. The directory is only accessed at runtime, not config time. workerd compile doesn't touch the directory. So it doesn't really make sense for them to use the import path meant for config.

I'll leave this open though with the action being that we should improve the documentation.

[isker]

Thanks for the reply. What you said all makes sense.

I did not consider the case of workerd compile. In that case it is not clear what “disk directory relative to the configuration file” (the thing I really want here) even means. I guess it could be relative to the binary. But I will just do the -d override to achieve what I want.