classification
Title: Python 3.3 Permission Error with User Library on Windows
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.3
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, jimp02, r.david.murray, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2012-11-01 17:28 by jimp02, last changed 2014-07-30 19:37 by zach.ware. This issue is now closed.

Files
File name Uploaded Description Edit
Projects.zip jimp02, 2012-11-01 17:28 Test case
Messages (9)
msg174434 - (view) Author: Jim Pattee (jimp02) Date: 2012-11-01 17:28
Python 3.3 Permission Error with User Library on Windows

I have certain scripts that run without error on Python 2.7 and 3.2. With Python 3.3 they get a "Permission Error". This does not occur with every script. The difference seems to be that the ones with a problem use a local user library. The ones without a local library are OK.

A test case is attached. Do not change the directory names. Double click on the file run_test.bat to run. You may need to change the path to the Python executable on your computer. It runs the script astyle_protected.py which uses the library libastyle.py. It runs OK with Python 2.7 and 3.2. But gets an exception with Python 3.3.
msg174436 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-11-01 18:29
Can you post the error, please?
msg174453 - (view) Author: Jim Pattee (jimp02) Date: 2012-11-01 19:37
Python 3.3  (64bit)
Traceback (most recent call last):
  File "file-py\astyle-protected.py", line 157, in <module>
    process_files()
  File "file-py\astyle-protected.py", line 30, in process_files
    get_header_variables(header_variables, header_path)
  File "file-py\astyle-protected.py", line 121, in get_header_variables
    file_in = open(header_path, 'r')
PermissionError: [Errno 13] Permission denied: 'C:\\Users\\jimp\\ZPythonPermissionError\\Projects/AStyle/src/astyle.h'
Press any key to continue . . .
msg174468 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-11-01 20:09
Is it possible you installed 3.3 differently?  For example 3.2 and 2.7 installed for all users and 3.3 for just you, or vice versa?

From the looks of the traceback there really is a permission problem with the file, since it is failing on a normal open.  (I thought at first it might be a result of the new import code in 3.3, but it doesn't look like import is involved.)

That filename looks awfully odd, though.  Is that a cut and paste error or is that really what the message says?  If it is you might want to track down how header_path gets constructed and see how it differs when run under the different python versions.
msg174561 - (view) Author: Jim Pattee (jimp02) Date: 2012-11-02 19:44
The problem is not file permissions nor the install. I did some further testing.

The problem actually occurs with the library calls at lines 23 and 25. I changed these lines to eliminate the library call by just hard coding the file path.

Change from:
line 23:    header_path = libastyle.get_astyle_directory() + "/src/astyle.h"
line 25:    beautifier_path = libastyle.get_astyle_directory() + "/src/ASBeautifier.cpp"

Change to:
line 23:    header_path = "C:\\Users\\jimp\\ZPythonPermissionError\\Projects/AStyle/src/astyle.h"
line 25:    beautifier_path = "C:\\Users\\jimp\\ZPythonPermissionError\\Projects/AStyle/src/ASBeautifier.cpp"

When run with the changes the program worked. The problem is apparently with the library call, not the file itself.

Then I changed the same instructions to get the file name using the same instructions that the library program used. The library program uses “sys.path[0]” to get the directory containing the executed script.

Change to:
line 23:    header_path = sys.path[0] + "/../AStyle/src/astyle.h"
line 25:    beautifier_path = sys.path[0] + "/../AStyle/src/ASBeautifier.cpp"

This also worked.

I want to do some more testing this weekend. I will hopefully have more info on Monday. Thanks for your input on this.

Apparently this is not a problem on your PC. I have run this on both Windows 7 and Windows 8. I get the same results (a Permission Error) on both.
msg174562 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-11-02 19:56
Well, I run linux, not Windows.  I haven't even looked at your code, frankly, since it is a zip file and includes third party stuff.  Maybe a windows dev will find time to look at it.
msg174643 - (view) Author: Jim Pattee (jimp02) Date: 2012-11-03 16:06
You have been in contact with my friends at Mensa.

Further information:
Just branching into the library causes a problem with permissions when opening files, even if the library just immediately returns.
Opening the file in the library, before returning to the calling program, will work.

You definitely have a problem somewhere.
msg224323 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-30 16:34
Works fine for me on Windows 8.1 64 bit using 3.4.1 and 3.5.0a0.  Can one on our Windows gurus confirm this please.
msg224341 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2014-07-30 19:37
Jim, is there any way you could cut down your example to something small and self-contained?  It may be that the process of doing that leads to a problem in your code.  As it is, I cannot reproduce your error, or pick out what might be causing it.  From a brief glance, I have a few suggestions, though:

- Don't use sys.path[0] to determine where the file lives, it's not a reliable indicator.  Try using 'os.path.dirname(__file__)' instead (or 'os.path.dirname(os.path.abspath(__file__))' if __file__ is relative, which should only be the case when passing the filename directly to Python as a relative path).
- Use 'os.path.join()' instead of adding strings to make paths.  Shouldn't matter, but makes things cleaner.
- (Unrelated, but) it's really not very nice to change the display color without changing it back.  On Windows, 'color' affects the entire window, not just your output, and it lasts past the death of your process.

Until you can provide a short (200 lines or less across 5 files or less) reproducer, there's not much we can do, so I'm closing the issue.  If you can provide one, please do so and I'll happily take a look!
History
Date User Action Args
2014-07-30 19:37:16zach.waresetstatus: open -> closed
resolution: works for me
messages: + msg224341

stage: resolved
2014-07-30 16:34:17BreamoreBoysetnosy: + tim.golden, BreamoreBoy, zach.ware, steve.dower
messages: + msg224323
2012-11-03 16:06:30jimp02setmessages: + msg174643
2012-11-02 19:56:31r.david.murraysetmessages: + msg174562
2012-11-02 19:44:15jimp02setmessages: + msg174561
2012-11-01 20:09:11r.david.murraysetmessages: + msg174468
2012-11-01 19:37:28jimp02setmessages: + msg174453
2012-11-01 18:29:17r.david.murraysettype: crash -> behavior

messages: + msg174436
nosy: + r.david.murray
2012-11-01 17:28:43jimp02create