Please see my follow up reply. The file extension may not have anything to do with this.
I wrote a simple derivation file that I intend to nix-build with. However, depending on the file extension of the files that are passed into the derivation, nix-build fails with
error: getting status of '/nix/store/yf5d7g2brgb7pyfxkljx9911k6grapkm-rcfile.sh': No such file or directory
But if I change the files to not have a file extension, the issue goes away. Is this intentional behavior, and why is this happening?
Actually I completely give up, renaming either of runner and rcfile to arbitrary filenames (not just file extensions) leads to nix-build either erroring or not erroring seemingly arbitrarily (but deterministically). I have no idea why these files just won’t get moved into /nix/store sometimes and not other times. Randomly adding / removing characters from either file name fixes and causes this issue unpredictably.
Not sure if this is relevant but I am using nix-user-chroot since the machine I’m running Nix on does not give me sudo permissions.
Actually neither of these derivations should work (and on NixOs they all fail) as you are using mv (move) instead of cp (copy). Basically your are moving a file that just can’t be moved because it is supposed to be in a read-only partition. Maybe nix-user-chroot checks not properly your permissions and sometimes allow you to do this forbidden operation.
That said I am not having the same error as you with the derivation, I get
this derivation will be built:
/nix/store/vrngqibkplj8gbs01b4s782xb3ln1nfd-my-bash.drv
building '/nix/store/vrngqibkplj8gbs01b4s782xb3ln1nfd-my-bash.drv'...
mv: cannot move '/nix/store/nij5ig0pca9r4lwyy42nbw2mfz9g0cmh-runner' to '/nix/store/k788k562d7g9yw1l80vzfmsv7cp0cwak-my-bash/shell.sh': Operation not permitted
mv: cannot move '/nix/store/6x6nzz49sj58b0px4pmrjigww8sh8v35-rcfile' to '/nix/store/k788k562d7g9yw1l80vzfmsv7cp0cwak-my-bash/bashrc': Operation not permitted
chmod: cannot access '/nix/store/k788k562d7g9yw1l80vzfmsv7cp0cwak-my-bash/shell.sh': No such file or directory
So maybe your are experimenting another problem (maybe due to the fake chroot? I read that proot does not implement a rename syscall (and some people prefer a fork by termux for this reason) but I’m not sure if nix-user-chroot use proot actually, it seems to use user namespace)… in any case please try to replace mv with cp and paste the full error you get (do you get this error before or after the script is run for instance?).
Another issue that popped out at me is that runner.sh contains references to ./bash and ./bashrc, neither of which I would expect to resolve to anything, though I don’t know precisely what context you mean to run the final $out/shell.sh in…
I still get the same error; my issue seems to be occuring before builder.sh is ran.
Yes currently it is incomplete; however, my current issue occurs without running it.
My system probably doesn’t use proot; it uses user namespace since the system supports it. In any case, the issue seems to be independent of the behavior of builder.sh :(.
I suspect the problem is actually the mv command and the lack of proper sandboxing. The build process removed the file unexpectedly by doing mv instead of cp, leading to a mismatch between the nix database and the nix store. You need to rectify the mismatch before things will work properly again.
Basically, nix thinks the store path is already there, so it doesn’t recreate it, then it actually isn’t there, so when it goes to build the thing depending on it, it freaks out.
I’ve never really needed to fix that kind of problem before, but my first thought is to try to use the store verification tools already in nix (nix-store --verify, and similar), and hope you can restore sensibility.
Hey tysm, it looks like this is the issue. To (temporarily) fix this issue, I replaced the mv with cp and renamed all of the files being copied.
How would you fix this the “right” way though? I ran nix-store --verify and tried commands such as nix build --rebuild -f simple.nix but it complained that “some outputs of the derivation were not valid so checking is not possible”, and for nix store repair -f simple.nix it complained that the path to the realization was not valid.
I’m not sure. It’s not something I’ve personally needed to deal with.
Based on my understanding, after a nix-store --verify, the next time you try to build something that involves the store path that was in a mismatched state, it should recreate it, ending the problem. That’s just my theoretical understanding, though.
nix-store --verify --check-contents --repair will fix your entire store. The docs are right that this is expensive, so the two commands documented after it tend to be used more, though in this case it might make sense to properly verify your store once. Might have to run it over night.