Peter Simanyi <psima...@namcobandaigames.com> 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 solution. Note that the line immediately following the chmod 0666 is an unlink call, which will delete the file if the user had sufficient permission to chmod the file to 0666. I suppose the meta-level description of the problem is: [1] Without the chmod 0666, the unlink will fail if the file is 0400 or similar. [2] With the chmod 0666, the unlink succeeds, and the file will be recreated with new permissions (not 0666: I believe my tests show 0444) after the post-unlink file creation. [3] Someone familiar with windows should analyze, propose a solution, test it under all relevant scenarios of file/group ownership (and again the chmod is only required on Windows), and on XP/Vista/Win7. The only problem I can see with the chmod 0666 is if for some reason the file still exists with bad permissions after the unlink. Since this is a low-overhead operation compared to the time to regenerate the .pyc file, I think that it would be reasonable to have an #ifdef MS_WINDOWS, if the file exists after the unlink(), print a big warning message that will always be visible even if -v is not used when invoking Python. This is getting complicated enough that you may want to see if you can get someone else to review it for ideas about how to address the chmod/unlink code. I am certainly not a Windows expert hence I'm making a best Unix-like attempt to analyze and test fixes. Good luck and thanks. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6074> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com