We have tested back and forth so we are pretty sure the issue exists in the latest version but not in alpha10. We can also see that building several times will eventually succeed (because of what you write above), but we have a lot of libraries so that would mean a lot of fails before we are through them all. Arguably this is an acceptable trade-off but I think that's We have used this setup for several months, and yesterday after updating composer was the first time we ran into this issue.

Reproducing this myself and looking at the code, I don't believe 051b7bd has any impact on this issue.Ĭhecking the file ownership prior to invoking touch() would resolve this issue but would also prevent cache pruning from operating as expected i.e., recently accessed files could be removed from the cache. Just to be clear, touch() (and the underlying utime operation, which is failing in your case) was already invoked prior to 051b7bd. I've seen this myself when reproducing this issue. Even if you build repeatedly with 051b7bd you should see successful builds. It is then downloaded afresh and re-created in the cache directory with the correct ownership on the following build, and so that build will succeed. In the case of this error, the file with the wrong (or at least different) ownership is removed by Composer from its cache during the failed build. I'm able to reproduce this error both on 1.0.0-alpha10 and I think I know why it worked for you after rolling back to alpha10: whenever Composer fails to copy a file from its cache directory it will attempt to delete that file from its cache.

Unable to set utime