nix path-info on binary caches missing names

[lheckemann]

Describe the bug

When nix path-info --all is used on a flat-file binary cache, the names of the store paths are all replaced with x:

Nix 2.4:

$ nix path-info --all --store file://$PWD 2>/dev/null | head
/nix/store/0009k6pqqcx4yx7rd4y33g9wazik8n05-x
/nix/store/000fllqdzw0dn6ajq7lbmx3akdd81zvl-x
/nix/store/000hgliydgbvhr1bkigd1avgzwfc0xgb-x
/nix/store/0011c1hv6yshgg3y9c68hjf9xrkl2hcp-x
/nix/store/0011hnawgw4kiwk59va5cin7bgyr6v1c-x
/nix/store/00193g9911rsmifv7s4m30bhis5fjizx-x
/nix/store/001s0nhljrr1v9kqpwcnq4wnnnpbhgac-x
/nix/store/001xf6lf19zn7facbvwwpxdnpl3wbnm8-x
/nix/store/0020ild6hvqdxx8iq7rjm2ixzikn24bh-x
/nix/store/00258hkg3wg99cw92vk6aj8jw1669swi-x

Nix 2.3.x:

$ nix path-info --all --store file://$PWD 2>/dev/null | head
/nix/store/0009k6pqqcx4yx7rd4y33g9wazik8n05-ruby2.7.4-actionview-6.1.4.1
/nix/store/000fllqdzw0dn6ajq7lbmx3akdd81zvl-unit-systemd-networkd-wait-online.service
/nix/store/000hgliydgbvhr1bkigd1avgzwfc0xgb-readline-6.3p08-man
/nix/store/0011c1hv6yshgg3y9c68hjf9xrkl2hcp-python3.8-authheaders-0.13.0
/nix/store/0011hnawgw4kiwk59va5cin7bgyr6v1c-etc-hostname
/nix/store/00193g9911rsmifv7s4m30bhis5fjizx-array_includes___array_includes_3.1.3.tgz
/nix/store/001s0nhljrr1v9kqpwcnq4wnnnpbhgac-unit-getty-.service
/nix/store/001xf6lf19zn7facbvwwpxdnpl3wbnm8-vm-test-run-containers-ipv4-ipv6
/nix/store/0020ild6hvqdxx8iq7rjm2ixzikn24bh-libjack2-1.9.17
/nix/store/00258hkg3wg99cw92vk6aj8jw1669swi-hook

Steps To Reproduce

nix-build '<nixpkgs>' -A hello && nix copy --to file:///tmp/cache ./result && nix path-info --store file:///tmp/cache --all

Expected behavior

All paths are printed with their names.

nix-env (Nix) 2.4

[edolstra]

Yeah, this is expected behavior since it's too expensive to fetch every .narinfo file.

[lheckemann]

Then maybe --all should error out on stores where it's considered too expensive? Giving incorrect information instead seems like a bad idea.

EDIT: also, this command does read all the narinfos and reports wrong path names. This is the case even if --json is given, which necessarily reads the narinfos anyway.