This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jafo
Recipients jafo, loewis, nbecker, owsla
Date 2008-01-16.08:37:13
SpamBayes Score 0.0076377513
Marked as misclassified No
Message-id <1200472636.8.0.696157658658.issue1747858@psf.upfronthosting.co.za>
In-reply-to
Content
I've reviewed the chown system call under Linux and I think the included
patch will resolve the problem.  With that patch on a Fedora 8 64-bit
system I'm getting:

>>> os.stat('/tmp/foo')
posix.stat_result(st_mode=33188, st_ino=5111823, st_dev=64769L,
st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1200469633,
st_mtime=1200469633, st_ctime=1200469657)
>>> os.chown('/tmp/foo', 4294967294, -1)
>>> os.stat('/tmp/foo')
posix.stat_result(st_mode=33188, st_ino=5111823, st_dev=64769L,
st_nlink=1, st_uid=4294967294, st_gid=0, st_size=0, st_atime=1200469633,
st_mtime=1200469633, st_ctime=1200469683)
>>> 

However, it's unclear to me whether there are any platforms that might
define uid_t as signed, and if so whether this code would do the right
thing on those platforms.

I don't know of a way to do it in C off hand, but perhaps we could check
the exact type of the uid_t and gid_t types and see if they're signed or
unsigned and use that combined with sizeof(uid_t) to use exactly the
correct ParseTuple format string.

I've attached a patch that dynamically tries to figure out the size to
use.  Does this seem overly-heavy?  If it seems appropriate, the same
would need to be applied to the other chown functions.
History
Date User Action Args
2008-01-16 08:37:17jafosetspambayes_score: 0.00763775 -> 0.0076377513
recipients: + jafo, loewis, nbecker, owsla
2008-01-16 08:37:16jafosetspambayes_score: 0.00763775 -> 0.00763775
messageid: <1200472636.8.0.696157658658.issue1747858@psf.upfronthosting.co.za>
2008-01-16 08:37:15jafolinkissue1747858 messages
2008-01-16 08:37:13jafocreate