[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Please at least crash with an exception instead: add > one easy check to py_compile.compile() and complain if cfile points > to an existing non-regular file. That's a good point (except that symlinks should probably be allowed too). -- __

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > I fixed syntax sanity check in Portage (package manager in Gentoo) to > avoid breaking system. This sanity check is always run during > upgrade of Portage itself. Well, we could add a dedicated function for sanity checking, then. -- title: py_compile.

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Arfrever Frehtes Taifersar Arahesis added the comment: I fixed syntax sanity check in Portage (package manager in Gentoo) to avoid breaking system. This sanity check is always run during upgrade of Portage itself. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=e8d1337b

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Armin Rigo added the comment: My point is that in five years' time some existing well-tested sysadmin-like program will be run with Python 3.4 for the first time, and suddenly whole systems will break. I don't want to sound negative but this is the worst behavior ever (with the possible excep

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: Yes, the switch to renaming can change behaviour in some corner cases (I say "corner cases" because the expected situation is to have your pyc files be regular files, not symlinks or character devices). Python is certainly not the only application where you ca

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Armin Rigo added the comment: Can someone confirm the answer to Arfrever's original question: a seemingly innocent use case of py_compile.compile(), which works fine until Python 3.3, when executed as root, can in Python 3.4 fundamentally break down a complete Posix system in a non-obvious way

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > > Ah, right. Well, there would be an argument not to use os.replace() in > > py_compile, since it's an offline processing step which generally > > shouldn't race with another (online) processing step. > > But I think that's not necessarily true. > > http://

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Barry A. Warsaw added the comment: Antoine says: > Ah, right. Well, there would be an argument not to use os.replace() in > py_compile, since it's an offline processing step which generally > shouldn't race with another (online) processing step. But I think that's not necessarily true. http:

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Changes by Brett Cannon : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Roundup Robot added the comment: New changeset 55806d234653 by Brett Cannon in branch 'default': Issue #17222: Document that py_compile now uses importlib for its file http://hg.python.org/cpython/rev/55806d234653 -- nosy: +python-dev ___ Python track

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: Exactly, and I don't want to have to slice up the internal API anymore in order to support this edge case which I don't think is important enough to support. -- ___ Python tracker _

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: Ah, right. Well, there would be an argument not to use os.replace() in py_compile, since it's an offline processing step which generally shouldn't race with another (online) processing step. Still, I wonder what the use case is (apart from the /dev/null case f

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: I think Arfever is more frustrated by the os.replace() call than the permissions. -- ___ Python tracker ___ _

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Of course, this won't recreate symlinks and the like. But I don't think > we can do something for that anyway, since we want to replace to happen > automatically. I meant: we want the replace to happen atomically :-) -- __

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Use the mode how exactly? I mean isn't the problem the os.replace() > call and not os.open() on the source file? If you want to reproduce the original file's access rights, you have to pass the right mode flags to os.open(). Of course, this won't recreate syml

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: Use the mode how exactly? I mean isn't the problem the os.replace() call and not os.open() on the source file? -- ___ Python tracker ___

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Unless there is some way that I can't think of to have the atomic write > still exist but not change the type of file it replaces How about using the `mode` to write_atomic? (which, incidentally, is already used to mirror the .py file's permissions in Source

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: So that all happens because importlib does an atomic write of the file which uses os.replace(): http://hg.python.org/cpython/file/83d70dd58fef/Lib/importlib/_bootstrap.py#l121 . Unless there is some way that I can't think of to have the atomic write still exis

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Arfrever Frehtes Taifersar Arahesis added the comment: py_compile.compile() was always replacing contents of target file, but was not causing that a given link name would refer to a different inode. builtins.open() has correct behavior: # stat /dev/null File: ‘/dev/null’ Size: 0

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Arfrever Frehtes Taifersar Arahesis added the comment: In case of /dev/null, the main problem is that it became a regular file. It was previously a character device. Writing to character devices should not replace them. What about problem with symlinks?: $ cd /tmp $ touch test.py $ ln -s targe

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: So py_compile always replaced the file, even in Python 3.3: http://hg.python.org/cpython/file/79ea59b394bf/Lib/py_compile.py#l141 (this is why I changed the title of the bug). What did change, though, is that py_compile now writes bytecode files just as import d