homepage

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.