Changing permissions of an input file does not cause its actions to rerun

[mmorearty]

This is not affecting me personally and I consider it pretty low priority — in fact I'm not sure if you would consider it a bug — but I'm filing it in case it's something you want to address.

Description of the problem / feature request / question:

Changing the permissions of an input file (e.g. with chmod) do not cause any actions that have that file as an input to rerun. Seems like this might be a bug, although the only scenarios I've been able to come up with are somewhat contrived, such as the example below.

If possible, provide a minimal example to reproduce the problem:

BUILD file:

genrule(
	name = "main",
	srcs = ["main.in"],
	outs = ["main.out"],
	cmd = "if [[ -x $(SRCS) ]]; then echo $(SRCS) is executable > $@; else echo $(SRCS) is not executable > $@; fi"
)

Then, touch main.in and then bazel build :main. As expected, bazel-genfiles/main.out will say: main.in is not executable

Then, chmod +x main.in and bazel build -s :main. Nothing rebuilds, and bazel-genfiles/main.out has not changed.

Environment info

• Operating System: OSX and Linux

• Bazel version (output of bazel info release): 0.5.2

[aehlig]

As your example shows, it affects correctness, so it certainly is a bug.

A more realistic example, albeit with significantly worse consequence, is following.

genrule(
  name = "foo",
  tools = ["dofoo.sh"],
  cmd = "$(location :dofoo.sh) > $@",
  outs = ["foo.out"],
)

Now, if the permissions of dofoo.sh are initially correct bazel build ... will work fine. Now chmod u-x dofoo.sh and bazel build ... will still report everything fine. But after a bazel clean suddenly things will break. Those breakages that can go unnoticed for a while are actually quite dangerous.

If you don't like bazel clean, the following scenarios will also break things.

• Rename the work directory (this is particular funny, as renaming back will magically "repair" things).
• Someone else checking out the same sources with the same permissions.

[ulfjack]

I agree with @aehlig that this is a correctness issue. We've never tracked mods, and it's never been a problem in practice, though.

[dslomov]

@ulfjack what's the right category for this?

[ulfjack]

I don't see any category more appropriate than misc.

[ulfjack]

We're now triggering on ctime everywhere, which, in principle, detects mod changes. However, our action cache does not take mods into account for the action cache entry, which would be the next step here - it's not a conceptually complicated change, but it will increase memory consumption by a bit. We're also not tracking mods during remote execution or for the spawn cache.

[ulfjack]

I think if we put the mods into FileContentsProxy, and then use them when we create the action cache entry, that would be straightforward and fix action caching.

[wchargin]

Here is another repro of what I presume is the same root cause. Setup:
empty WORKSPACE, empty file called ex, and one build rule:

sh_binary(
    name = "must_be_executable",
    srcs = ["ex"],
)

On initial run, as expected, this fails to build:

$ bazel build :must_be_executable
INFO: Found 1 target...
ERROR: /tmp/tmp.IdOEStohFm/BUILD:1:10: failed to create symbolic link 'must_be_executable': file 'ex' is not executable
Target //:must_be_executable failed to build
FAILED: Build did NOT complete successfully

After chmod +x, as expected, it builds:

$ chmod +x ex
$ bazel build :must_be_executable
INFO: Found 1 target...
Target //:must_be_executable up-to-date:
  bazel-bin/must_be_executable
INFO: Build completed successfully, 3 total actions

But after chmod -x, it still builds, when it should fail:

$ chmod -x ex
$ bazel build :must_be_executable
INFO: Found 1 target...
Target //:must_be_executable up-to-date:
  bazel-bin/must_be_executable
INFO: Build completed successfully, 1 total action

And running bazel clean fixes that:

$ bazel clean
$ bazel build :must_be_executable
INFO: Found 1 target...
ERROR: /tmp/tmp.IdOEStohFm/BUILD:1:10: failed to create symbolic link 'must_be_executable': file 'ex' is not executable
Target //:must_be_executable failed to build
FAILED: Build did NOT complete successfully

I was attempting to use a sh_binary here as a workaround for #13180,
to create a target that fails to build unless a certain file is marked
executable. But now I’m blocked on this issue instead of that one.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen (or ping me to reopen) if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[georgegiovanni]

Was this issue fixed? This should not be closed.