Re: Change in Install behaviour: no longer makes target file writable after copying, causing build errors
Mats Wichmann <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <[email protected]> |
On 4/11/21 2:02 PM, Thomas Berg wrote: > Hi, > > After upgrading to SCons 4.X, I'm experiencing build failures in the > following use case: > - our scons build copies files from a read-only location > - whenever the source file changes, and scons copies the updated file, > the build now fails to overwrite the previously copied file, because > it's now read only > > In earlier SCons versions, the copied file was always kept writable. We > were happy with this, and I think it makes more sense. So at least in > our case this is a regression. > > Not sure if there are important use cases where you would want the > writable property to be propagated? > > I checked the history and found > commit 0f3d4d1912b4d2378c989ea56a91ca2d4861d599, which removes an > explicit os.chmod call in SCons/Tool/install.py (in the copyFunc > function). It appears to be general code maintenance, rather than a > bugfix. I believe this is the cause, although I haven't verified it yet. As the guilty party, I can confirm it's the former - scons was using a "vendored" copy of a Python library routine from more than a decade ago, and there had been a lot of improvements in the Python lib (and the performance of the various file copying routines in Python has always been a sort point and recently much improved, so I attempted to rebase it. I can't answer at the moment whether this (dropping the chmod) was a change the Python team made for some reason, or whether it was part of our original vendored changes but not marked as such so I missed that. I think in general copying likes to preserve reasonable bits of metadata, but one can argue what's "reasonable. The POSIXy behavior seems to agree with the current behavior you're seeing: $ touch X $ chmod 0444 X $ cp X Y $ cp X Y cp: cannot create regular file 'Y': Permission denied That doesn't mean it might not be reasonable to put it back to the earlier behavior... _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users