file permissions on windows XP (home)

[barney]

I'm trying to write to an existing file under windows XP (home). The
files are in 'My Music' which I think may be treated in some special
way under XP. The relevant python code is as follows:

os.chdir(dir)
os.chmod(filename, 0744)
print "Okay to write = "+str(os.access(filename, os.W_OK))
afile = file(filename, 'r+b')

When I run this I get the following console output:

Okay to write = True
Traceback (most recent call last):
File "c:\temp\eyed3-0.6.6\src\test.py", line 28, in ?
processFiles(root,files)
File "c:\temp\eyed3-0.6.6\src\test.py", line 24, in processFiles
afile = file(filename, 'r+b')
IOError: [Errno 13] Permission denied: "02 - New Year's Day.mp3"

If I look at the files in explorer then the read only flag is not set.
If I change to cygwin and then do an ls -l I get something like:

-r--r--r-- 1 Barney None 4142103 Feb 28 1999 02 - New Year's Day.mp3

If I do a chmod 644 from bash first then the python works fine?

I'm at a loss to understand what is going on.

Why is python returing True from os.access?
Why isn't chmod doing anything?
Why is cygwin able to sort the problem out?

Thanks
Barney

p.s. I'm using ActiveState Python 2.4

 

[Peter Hansen]

barney wrote (having trouble with a file):
[snip]

IOError: [Errno 13] Permission denied: "02 - New Year's Day.mp3" [snip]
I'm at a loss to understand what is going on.

Why is python returing True from os.access?
Why isn't chmod doing anything?

Check your results using os.stat() after doing that, perhaps? If it
shows the right values for the permissions, then clearly the problem has
nothing to do with Python per se, or your own code.

Why is cygwin able to sort the problem out?

I suggest (a) trying again, making sure that the file is not in use in
another application such as the Media Player, and (b) trying with some
other file that you've just created for the purpose of testing this to
compare your results.

I just tried the whole sequence you showed without any problems, on a
file called "test" that I created in my own My Music folder. (Not using
cygwin, however, since I don't use it, but in this case there was no
need for me to use it anyway.)

-Peter

 

[Duncan Booth]

Check your results using os.stat() after doing that, perhaps? If it
shows the right values for the permissions, then clearly the problem has
nothing to do with Python per se, or your own code.

And also remember that in windows the mode in os.chmod and os.stat is only
loosely related to the actual permissions on the file. In particular there
is a 'readonly' flag which is separate from whether any particular user
or group has write access. The only way to tell whether you have access to
a file in windows really is to try to open it and handle the exception.

Try using the properties panel, or the windows CACLS to display the
security permissions on the file.

If you start with a plain file, then you and administrators probably have
full access (CACLS will display 'your username:F'). If you use Python to
set an access mode, it simply tries to toggle the attributes on the file
itself. If you use Cygwin's chmod it will mess about with the security
permissions in an attempt to get as close to the Unix file mode as it can,
so your nice simple 'F' mode might become something truly horrendous:

Before:
C:\temp>cacls testfile.txt
C:\temp\testfile.txt BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
DELL5150\Duncan:F
BUILTIN\Users:R

C:\temp>\cygwin\bin\chmod 744 testfile.txt

C:\temp>cacls testfile.txt
C:\temp\testfile.txt DELL5150\Duncanspecial access
STANDARD_RIGHTS_ALL
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
STANDARD_RIGHTS_REQUIRED
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_EXECUTE
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES

DELL5150\Nonespecial access
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_READ_ATTRIBUTES

Everyonespecial access
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_READ_ATTRIBUTES

BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
BUILTIN\Users:R

 

[barney]

Thanks,

I tried creating a test file but I get "Access is denied" from windows
explorer! The folder appears to be read only but when I try and uncheck
read only/apply/repopen the folder properties its still read only. This
read only flag seems to propagate down from the My Music directory but
unchecking it there also has no lasting effect.

I realise that theses are windows rather than python issues but I would
expect there would be some reliable way of changing the file
permissions from within python. I'm updating ID3 tags in MP3 file to
give some context. If I use something like winamp to make the change to
the ID3 tag then the file is updated with no permission errors so there
must be a way....

I have added a stat call to the code which returns:

(33206, 0L, 2, 1, 0, 0, 4142103L, 1118176036, 920221388, 1111442057)

and this is the output of cacls (didn't know about this command):

C:\Users\Barney\My Music\U2\The Best Of 1980 - 1990 (US CD 1)\02 - New
Year's Day.mp3 XPHOME\Barneyspecial access
STANDARD_RIGHTS_ALL
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
STANDARD_RIGHTS_REQUIRED
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES

XPHOME\Nonespecial access
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_READ_ATTRIBUTES

Everyonespecial access
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_READ_ATTRIBUTES


I'm not entirely sure how to interpret these but will do some reading.
In the meantime if someone could show me some python to force the file
to be writeable that's all I really need at this stage.

Thanks
Barney

 

[Duncan Booth]

I realise that theses are windows rather than python issues but I would
expect there would be some reliable way of changing the file
permissions from within python. I'm updating ID3 tags in MP3 file to
give some context. If I use something like winamp to make the change to
the ID3 tag then the file is updated with no permission errors so there
must be a way....

So it looks as though you have been using cygwin to set the file's access
permissions and cygwin uses a complex mapping of unix's permission bits
onto file security, whereas Python uses the more common, but incomplete
mapping as implemented by the C runtime library.

The relationship between commands is that Python's chmod is equivalent to
using the command line ATTRIB command, but Cygwin's chmod is equivalent to
using both ATTRIB and CACLS.

I can think of three options open to you:

a) Let cygwin fix what cygwin broke:

os.system('\\cygwin\\bin\\chmod u+rwx ' + filename)

b) Use cacls to fix it:

os.system('cacls %s /P %s:F' % (filename, username))

c) Use win32security.SetFileSecurity()

See http://mail.python.org/pipermail/python-win32/2004-July/002111.html for
a thread on using this api.

 

[barney]

Thanks, I will go the win32security.SetFileSecurity route. It seems a
pity that I can't use platform independant code to sort this out but I
guess you're saying that I've managed to get my files into a non
standard state that needs non standard code to sort it out. I wonder
how winamp/itunes manage to bypass it.

Barney

 

[gratzel]

I have noticed a bug that if I have a folder open for viewing in
Windows Explorer with Thumbnail view enabled that I often run into
inexplicable problems with modify permissions, say when I want to
rename or delete an item. Changing the view to Detailed or rebooting
seems to make the issue go away.

 

[Ivan Van Laningham]

Hi All--

I have noticed a bug that if I have a folder open for viewing in
Windows Explorer with Thumbnail view enabled that I often run into
inexplicable problems with modify permissions, say when I want to
rename or delete an item. Changing the view to Detailed or rebooting
seems to make the issue go away.

Makes sense. With the thumbnail view enabled, Windows has to monitor
every file in the directory for changes, and update the thumbs all the
time. With other types it watches for changes, but it doesn't have to
be so obsessive about it. Now that I think about it, the times that
I've had permission trouble it's always been with thumbs.

Not definitive, but worth looking out for.

Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours