[Question] lost executable permissions?

[jorgecarleitao]

Is it possible that files lose permissions when cached (tarball with compression)?

I have a run where, after recovering a cached file, it became non-executable: https://buildkite.com/test-811/example/builds/73#3de87972-da8a-487c-ab48-005d369a2ac3

I am trying to understand if this comes may be from this plugin or is something else.

[gencer]

In Linux, tar stores both permissions and properties of the file. In macOS, I believe this is the same. I think it should cache permissions too.

So either;

a. I am wrong and macOS's BSD TAR does not store permissions b. You are using scoped executables. (User A has permission to execute it but you are restoring cache on User B that has no permission to execute that specific binary. I am 99% sure this is not the case. I mean, I just see this case few times in my life.)

I'll test this out on our macOS runners as soon as possible.

[gencer]

In addition to my previous answer, temporary solution until a permanent one from me to use chmod in - command:. Just give binaries its permissions (0755) back before executing it.

[gencer]

P.S.: Could also this be the case?: https://askubuntu.com/questions/184280/bash-filename-cannot-execute-binary-file

Did you cached mixed-architecture (maybe?)

[jorgecarleitao]

The executable is a by-product of cargo test. This command is spiritually something like

• cargo build test-binary
• cargo run test-binary

cargo knows when to rebuild a test binary (for a target arch, flags, etc.), before cargo run test-binary. In this case, I am caching the binary (together with everything else), and because between builds there is no change in the source code, it skips cargo build -> test-binary and just runs cargo run test-binary, which is failing.

This only happened after I successfully cached dependencies, which is the reason I am considering that the caching affected permissions.

The reason it is not so easy to just set permissions is that these files have non-deterministic names: they are named after an hash and stuff. I could chmod +x on the whole directory, but that has some security implications.

Another solution is to remove all executables before caching. re-building them is a small effort. Of course avoiding this would be even better ^_^

I do not think It mixed architectures as I am running everything on a single agent (which happens to be my pc, so I can also test this locally).

[gencer]

I'll fire up some mac runners tomorrow for this case to see how behaves it. (Through, I also need to find a sample rust app with tests so that I can run cargo test then cache.)

[jorgecarleitao]

I am closing this as not a problem: the problem was that there were conflicting files in the directory because repo checkout was not cleaning the directory. BUILDKITE_CLEAN_CHECKOUT=true did it.

Thanks a lot for your patience and help, and sorry for the noise :/

[gencer]

Not at all. I'm glad that you figured it out. 🎉🤞