ziglang
std.Build.Step.Run: fix depfile support
Added a check to confirm there are in fact output files to rename. Tests don't have any output file which in turn caused the tmp dir to never be created.
In local testing I haven't encountered any other failure yet.
New failure encountered:
run markdown-renderer (foo): error: unable to rename dir '/home/kristoff/zine/sample_website/zig-cache/tmp/d83e225dbcbbfb63' to '/home/kristoff/zine/sample_website/zig-cache/o/698cbffc12254f84f2311f90ba39a9a1': PathAlreadyExists
Accorting to the doc comment of Dir.rename():
/// Change the name or location of a file or directory.
/// If new_sub_path already exists, it will be replaced.
/// Renaming a file over an existing directory or a directory
/// over an existing file will fail with `error.IsDir` or `error.NotDir
But it does have PathAlreadyExists in the error set and clearly it does return it.
I think you can simply remove the additional call to makePath() since you are intending to create the directory via the rename.
I think you can simply remove the additional call to
makePath()since you are intending to create the directory via the rename.
Is it guaranteed that o/ will exist when this code runs? My understanding is that rename will only create the tip directory, so if that's true then o/ has to be guaranteed to exist.
In the meantime I figured out which condition triggers the error I mentioned in my last comment: when from different inputs we create outputs that are already in the cache and then we try to move the temp file over already-present, identical files in the o/$digest directory.
According to the man pages rename will fail if the destination directory is not empty, so that's the full explanation of the last error I know of.
I've pushed a change where we simply delete the temp dir if we get back error.PathAlreadyExists.
Is it guaranteed that
o/will exist when this code runs? My understanding is thatrenamewill only create the tip directory, so if that's true theno/has to be guaranteed to exist.
No, but it is highly likely, so it should optimistically assume that it exists, while handling the case that it does not.
In the meantime I figured out which condition triggers the error I mentioned in my last comment: when from different inputs we create outputs that are already in the cache and then we try to move the temp file over already-present, identical files in the
o/$digestdirectory.
Different inputs will result in a different hash digest, so they will not collide with each other. Something is wrong with this reasoning.
According to the man pages rename will fail if the destination directory is not empty, so that's the full explanation of the last error I know of.
Better to not rely on the ability to overwrite an empty directory with rename. I don't think that is portable behavior.