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
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 can
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
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.
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:
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).
--
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17222
___
___
Python-bugs-list mailing
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.
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.
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
Changes by Brett Cannon br...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17222
___
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
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
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 rep...@bugs.python.org
http://bugs.python.org/issue17222
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
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 :-)
--
Brett Cannon added the comment:
I think Arfever is more frustrated by the os.replace() call than the
permissions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17222
___
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
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 rep...@bugs.python.org
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
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
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
22 matches
Mail list logo
