[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Marco Buccini : -- nosy: -markon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by desolat : -- nosy: -desolat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Kevin Chen added the comment: Okay just tried it. This is under Windows 7 x64. I created a .py file with read-only permission. When I import the .py module, the created .pyc doesn't have read-only permission. So it works as intended under Windows OS. As long as under posix system the created

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: No worries. If you could do a fresh build of the 2.7 branch and confirm this fix works for you, that would be great. -- ___ Python tracker ___ ___

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Kevin Chen added the comment: Hi Nick, Thank you so much for rolling out this change. I think your implementation of the fix is more elegant. I have learned a few things from you. I would love to keep helping to test/fix bugs for Python on Windows. Please contact me if there is anything you w

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Eric Snow added the comment: Sounds good. Thanks for getting this done, Nick. -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: For 3.3+ I ended up using a tweaked version of Eric's patch - I kept the general test structure, but used the behavioural test I had created (i.e. does updating the initially read-only source file affect a subsequent bytecode only import?), as well as the simple

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Roundup Robot added the comment: New changeset 8cf7f6fe4282 by Nick Coghlan in branch '3.2': Issue #6074: Actually delete the source file in the test as intended http://hg.python.org/cpython/rev/8cf7f6fe4282 -- ___ Python tracker

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Roundup Robot added the comment: New changeset bbb3459fbcb8 by Nick Coghlan in branch '3.3': Issue #6074: Apply an appropriate fix for importlib based imports http://hg.python.org/cpython/rev/bbb3459fbcb8 New changeset bedcc790c6e7 by Nick Coghlan in branch 'default': Merge fix from #6074 from 3

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Roundup Robot added the comment: New changeset df83d3bbd934 by Nick Coghlan in branch '2.7': Issue #6074: Actually delete the source file in the test as intended http://hg.python.org/cpython/rev/df83d3bbd934 -- ___ Python tracker

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: OK, it should just be the two importlib based releases affected now. -- versions: +Python 3.4 -Python 3.2 ___ Python tracker ___ __

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Roundup Robot added the comment: New changeset 3f6db10b7a69 by Nick Coghlan in branch '3.3': Dummy merge from 3.2, as that approach to resolving #6074 is not applicable to importlib http://hg.python.org/cpython/rev/3f6db10b7a69 -- ___ Python tracker

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Roundup Robot added the comment: New changeset 1856d57abfc8 by Nick Coghlan in branch '3.2': Issue #6074: Forward port Windows read-only source file fix from 2.7 http://hg.python.org/cpython/rev/1856d57abfc8 -- ___ Python tracker

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: Buildbots look happy, removing 2.7 from affected versions. -- versions: -Python 2.7 ___ Python tracker ___ ___

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Roundup Robot added the comment: New changeset 321414874b26 by Nick Coghlan in branch '2.7': Issue #6074: Restore the long-broken support for running with read-only source files on Windows http://hg.python.org/cpython/rev/321414874b26 -- nosy: +python-dev __

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: Ah, my test was buggy - the mtime wasn't reliably changing by enough, so the pyc wasn't always being rewritten. I changed it to force a big time delta by backdating the original source file. -- ___ Python tracker

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: Interesting - the test case I wrote for this was failing on Linux as well. Same fix worked both places, though (i.e. ensuring S_IWUSR is always set on .pyc files so they can be updated properly) 2.7 update incoming, we'll see what the Windows buildbots have to s

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: It's still on my list to follow up (along with the other contributions from the PyCon AU sprints). However, if Eric gets a Windows environment up and running before I get to it, I'm happy to hand the issue over (I rely on the buildbots to sanity check Windows fi

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Kevin Chen added the comment: Hi Eric, I am happy to install Python 3.3 on Windows and help you test this. Can you please give me some ideas on what I need to do? Do I sync to the latest Python 3.3 branch and compile? Then run some unit-test code? Which test files should I run? What should I

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Eric Snow added the comment: Well, the workflow on Windows is certainly different. I've run out of time to get this sorted out in the short term. However, the patch should be pretty close to what's needed. Obviously the posix-only bit doesn't fit for a Windows-specific test. -- __

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Eric Snow added the comment: Here's a patch for 3.3 with a test. Though, I'm still setting up my windows box for building Python, I wanted to get this patch up. On its own the test should fail on Windows. In that case, it should be backport-able. If no one has a chance to verify the test o

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: Adding 3.3 to affected versions, since I'm about to check in a fix for #2051 that will reintroduce this problem. -- nosy: +eric.snow versions: +Python 3.3 ___ Python tracker

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Kevin Chen added the comment: Hi I made the following patch for this issue. It addresses the #2051 security bug. So the .pyc and .pyo files are created using the same permission as .py The MS_WINDOWS version will chmod the permission of .pyc and .pyo files to write accessible before deleting

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: (Note: Kevin is looking into this at the PyConAU sprints) New test case needed (probably in Lib/test/test_import.py): - create .py file as 0400 - import it - check .pyc (or .pyo) file is 0600 That ensures the #2501 security bug remains fixed, while also addressi

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Nick Coghlan added the comment: OK, I tracked down the original reason for the behavioural change: #2051 The important aspect in that patch is preserving the *read* permissions from the .py file so we don't accidentally expose data to other users. Kevin's patch seems like a good approach for r

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Kevin Chen : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Kevin Chen added the comment: This is essentially the way things were done in version 2.5.4 of Python. The unlink() always succeeded, because the created .pyc file permission is always set to 0666 in the fd=open() function. This means the .pyc will never be created as read-only, and as long as

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Kevin Chen added the comment: I propose a fix: static FILE * open_exclusive(char *filename, mode_t mode) { #if defined(O_EXCL)&&defined(O_CREAT)&&defined(O_WRONLY)&&defined(O_TRUNC) /* Use O_EXCL to avoid a race condition when another process tries to write the same file. When that h

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by desolat : -- nosy: +desolat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Éric Araujo added the comment: Bug fixes go into 2.7 but not 2.6. See msg115664. -- nosy: +eric.araujo versions: -Python 2.6 ___ Python tracker ___ _

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Éric Araujo : Removed file: http://bugs.python.org/file18739/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Steve Thompson added the comment: Any idea if this will be fixed (at all) and/or back ported to 2.6.x or 2.7.x? On Fri, Sep 3, 2010 at 3:36 PM, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > This is still the case: on Windows, if foo.py is readonly, >python -

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Amaury Forgeot d'Arc added the comment: This is still the case: on Windows, if foo.py is readonly, python -c "import foo" generates foo.pyc with the readonly attribute. Tested with 3.1 and current py3k (where the file is named __pycache__\foo.cpython-32.pyc) -- nosy: +amaury.forge

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Steve Thompson added the comment: So what's the current status of this on Windows Platforms? -- nosy: +Steve.Thompson ___ Python tracker ___ _

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Antoine Pitrou added the comment: Apparently this may have become Windows-specific at some point. I can't reproduce under Linux with Python 2.6.5, 2.7 or 3.2. I get a strange warning with -v under 2.7, though: $ touch b.py && ~/cpython/27/python -v a.py 2>&1 | grep b.py # /home/antoine/py3k/_

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Dirk Jülich added the comment: Applies also to Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32. -- nosy: +mucisland versions: +Python 2.6 ___ Python tracker __

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Mark Lawrence : -- nosy: +brian.curtin versions: +Python 3.2 -Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: I verified that launching the script from a CMD.EXE window instead of from Cygwin also reproduces the "can't overwrite ZZZ.pyc". Here's a sample of "python -v" showing this: # C:\depot\central\ntf\tools\bin\build1.pyc has bad mtime import build1 # from C:\depo

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: Re: chmod 0666 inappropriate: I agree that leaving a file 0666 is inappropriate, however theoretically the code should never leave the file 0666 since the unlink will delete the file. The code was intended to show what the problem is by demonstrating a solutio

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Marco added the comment: TO pdsimanyi: chmod it's not appropriate to change the permissions as you made: 0666 et voilà. However, I don't understand if it can be a problem since you're using Cygwin (and Bash under Windows) or not. I think this because Windows is not POSIX compliant and under Wi

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: I realized that my patch, with a chmod(..., 0600), may not work under certain conditions where the original file is owned by a different user but the directory is group- or world-writable. A more likely correct fix would use chmod(..., 0666). At any rate: som

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: I have a fix for this. The code is Windows-only. It has been verified to work for attached test script showpycreadonlysleep.sh. It simply adds a "chmod" call. The issue is that the unlink() call silently fails if the file is readonly, but unlink() succeeds if

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: I may have a reason to analyze that would explain why this fails on Windows: the non-Windows code path in import.c's open_exclusive() contians an unlink(filename), but the Windows path does not. I'm going to try to build Python on Windows and add an unlink for

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: Re: Ubuntu: I can't reproduce the problem. At this point, I consider this problem Windows XP-only. Re: Windows & bash: I decided to verify that this problem occurs even if running outside of Bash in the native (and wonderful) shell CMD.EXE. It *does* occur. H

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Peter Simanyi added the comment: Oops, I was not accurate in reporting behavior: I now believe that this fails on Windows XP, but may work fine on Linux. Below are my results, showing reproducible failure on XP. The most important thing about this is: on XP, once the .pyc file is "broken", P

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Marco added the comment: Which version are you using? I've seen the source code of import.c (2.5 and 2.6) and it seems that in the 2.6 some bugfixes/features have been added. However, I've just used the version 2.7 and it works fine (as 2.6, since they have the same code (at least in import.c)

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Marco added the comment: It seems Python is using a default mask to compile modules. If you open a file b.py as "r", and you import it from a.py, you can see that b.pyc is: -rwxr-xr-x 1 marco marco9 24 mag 16:17 a.py -r--r--r-- 1 marco marco 10 24 mag 16:17 b.py -rw-r--r-- 1 marco marco 1

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Antoine Pitrou : -- priority: -> critical stage: -> needs patch versions: +Python 2.7, Python 3.1 ___ Python tracker ___ _

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

New submission from Peter Simanyi : Some source code control tools, like Perforce, by default sync files readonly, and it's useful to leave them readonly so that you can mark files changed by making them writeable even if they're not checked out (e.g. working offline). When python implicitly