When trying to work through some sstate sharing issues I had two users who are members of the same group building in different paths and b using a's sstate-cache. When b is building native packages the do_populate_sysroot_setscene() calls fail, as is to be expected (I believe), and BitBake sets off building my pseudo and -native recipes. quilt-native appears to be the first to compile and install and all seems well until it tries to create the siginfo file, this fails as the file already exists from user a. I would have assumed that if the sstate file from a couldn't be used the siginfo filename, which includes something which looks like a hash, would be different and that b would create a new siginfo file rather than trying to overwrite a's. a's sstate-cache is rw-rw-r-- so b can create files in a's sstate-directory but the siginfo files are created rw-r--r-- which seems fine except for in the above issue. I'm not sure what the right solution is here so hoping for some feedback/suggestions.
Was this not a race? Did the file from a not exist at the time the build started, hence it wasn't used?
(In reply to comment #1) > Was this not a race? Did the file from a not exist at the time the build > started, hence it wasn't used? It wasn't a race. a's build had completed long before b's even started.
I think what happened here was that some of the task checksums matches but not all for all tasks. Bitbake concluded it had to rerun other tasks completely to finish the build. I therefore think the behaviour is expected but we need to be more careful with permissions. I believe patches addressing the permissions have been fixed so this issue should be resolved.
Sounds reasonable.