Description
Access Control List (ACL) is how Windows handles file permissions.
A failure to read the ACL is not fatal, but may lead to issues with the permissions of the files created.
If a failed Windows API call caused the attempt to read ACL to fail, the error message gives the API call and failure code.
Reasons
When eMake receives a file from a cluster host, it places that file in a temporary directory (when possible, on the same device as the file belongs), and then moves the file into place at commit time. This can lead to problems on Windows because the file, when created, inherits the ACL specified by its parent directory, and simply moving it into place leaves it with the ACL from the temporary directory instead of the ACL it would have had if it were created in place.
To avoid this problem, eMake caches the ACL of each directory it works with, calculates the appropriate ACL for anything created in that directory, and applies the appropriate ACL to files in the temporary directory.
Fixes
The cacls command will display and edit ACLs from the Windows command line.
Example
WARNING EC1057: Unable to read ACL for directory m:/dist/fsf/PROJ/boost/1.33.1/common/include/boost/variant (m:/dist/fs/PROJ/boost/1.33.1/common/include/boost/variant: LookupAccountSid: The trust relationship between this workstation and the primary domain failed. (1789)): The operation completed successfully
Looking up 1789 in WinError.h, that is ERROR_TRUSTED_RELATIONSHIP_FAILURE.
The first thing to do in this case is to run cacls m:\1.33.1
to see what Windows sees. Normally, if LookupAccountSid() returns ERROR_NONE_MAPPED (“No mapping between account names and security IDs was done. (1332)”), we just give the name (not found) rather than erroring out.