[Scons-users] Change in Install behaviour: no longer makes target file writable after copying, causing build errors

Mats Wichmann mats at wichmann.us
Sun Apr 11 17:10:23 EDT 2021


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...



More information about the Scons-users mailing list