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

[Bill Deegan]

Indeed.
Here's the old logic.

shutil.copy2(source, dest)
st = os.stat(source)
os.chmod(dest, stat.S_IMODE(st[stat.ST_MODE]) | stat.S_IWRITE)

Interestingly previously the above would only apply to single file
Install()'s and not to whole directories worth which would use
shutil.copy2() (which copied permissions).
So the current code is more consistent than the previous code, but I can
understand your expectations..

I think ideally you could set the permissions for installing?
Maybe to be masked with original file..


On Sun, Apr 11, 2021 at 2:10 PM Mats Wichmann <mats at wichmann.us> wrote:

> 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
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20210411/0e5d70e6/attachment-0001.htm>