ArcGIS Server on Linux python unable to change file permissions.

[DanSlayback]

I've got a python program that needs to write to a log file. Usually that log file exists. If it doesnt, it needs to be created. And if its created, it needs to be group-writeable, because there are other programs that operate under other users that will need to write to it.

This all has worked fine using the python installed with ArcGIS Desktop 10.0 on Windows, but using 10.1 Server on Linux, as I now need to do, the group permissions are not getting set correctly, and using shutil to try to set them is failing.  And it works correctly using the standard python (version 2.6.6) installed on my workstation  (RHEL 6.2). So I'm not sure if the issue is python 2.6 vs 2.7, or if there are additional restrictions on the ArcGIS Server python. Here's what I'm talking about:

template.log is simply an empty file with both user and group permissions set to read-write:

-rw-rw-r--. 1 dan users       0 Jun  21 13:32 template.log

Simple code to illustrate:

import shutil

template = 'template.log'
newfile = '2012-172.log'

shutil.copy(template, newfile)
shutil.copymode(template, newfile)

Running the above in non-ESRI python 2.6.6:

$ python
Python 2.6.6 (r266:84292, Jun 18 2012, 09:57:52) 
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> template = 'template.log'
>>> newfile = '2012-172.log'
>>> shutil.copy(template, newfile)
>>> quit()
$
$ ls -l template.log 2012-172.log
-rw-r--r--. 1 ags users 0 Jun 21 13:33 2012-172.log
-rw-r--r--. 1 dan users 0 Jun 21 13:32 template.log

Just what I need. And I didnt have to bother with the shutil.copymode as the above maintains the source files' permissions.

But if I use ArcGIS Server's (10.1) python:

$ /home/ags/arcgis/server/tools/python
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> template = 'template.log'
>>> newfile = '2012-172.log'
>>> shutil.copy(template, newfile)
>>> 
[1]+  Stopped                 /home/ags/arcgis/server/tools/python
$ ls -l template.log 2012-172.log
-rw-------. 1 ags users 0 Jun 21 13:37 2012-172.log
-rw-r--r--. 1 dan users 0 Jun 21 13:32 template.log
$ fg

>>> shutil.copymode(template, newfile)
>>> quit()
$
$ ls -l template.log 2012-172.log
-rw-------. 1 ags users 0 Jun 21 13:37 2012-172.log
-rw-r--r--. 1 dan users 0 Jun 21 13:32 template.log

Note that the shutil.copymode isnt able to do anything, nor does it complain.

I've also done this with template.log owned by user ags instead of dan; same problem.

Thanks much for any clues or suggestions.

[BruceNielsen]

Could you put in a command like:

os.system('chmod go+r 2012-172.log')

to fix the permissions?

[DanSlayback]

i was actually trying to avoid using linux commands, because I wanted the code to work under either Windows or Linux. although clearly a simple check on the os and an if statement could solve that problem.

However, even this does not work using ESRI's installed python, and yet works with the OS-installed python! Quite bizarre:

$ /home/ags/arcgis/server/tools/python
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system('chmod g+w 2012-172.log')
os.system('chmod g+w 2012-172.log')
File not found

9009
>>> ^Z
[1]+  Stopped                 /home/ags/arcgis/server/tools/python
$ ls -l 2012-172.log 
-rw-------. 1 ags users 0 Jun 25 08:00 2012-172.log

And giving it the full path does not help.  Whereas, for system-installed python:

$ python
Python 2.6.6 (r266:84292, Jun 18 2012, 09:57:52) 
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system('chmod g+w 2012-172.log')
0
>>> 
[1]+  Stopped                 python
$ ls -l 2012-172.log 
-rw--w----. 1 ags users 0 Jun 25 08:00 2012-172.log

is this possibly correct, or is this likely a bug?