[issue1747858] chown broken on 64bit

2009-12-23 Thread Gregory P. Smith

Gregory P. Smith  added the comment:

indeed, those were missed.  fixed in trunk r77007 and release26-maint 
r77008.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2009-12-02 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Looking at posixmodule.c, perhaps other instances of parsing an uid_t or
a gid_t should have been fixed too (lchown, fchown for example)?

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-03-18 Thread Gregory P. Smith

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

backported to 2.5 in r61542 and r61544.

it'll go into py3k via the regular merges from trunk.

The fix just changed the int -> long and 'ii' -> 'll' and added unit
test coverage.

The patch attached to this bug was rejected as too complex:  If
conditional treatment of the types is ever needed it should be done at
build time via autoconf and not at runtime.

--
keywords:  -patch
resolution: remind -> fixed
status: open -> closed
versions:  -Python 2.5

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-03-18 Thread Gregory P. Smith

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

fixed in trunk r61540.

I'm leaving this open until i backport it to release25-maint.

--
resolution:  -> remind
versions:  -Python 2.6

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-03-17 Thread Gregory P. Smith

Changes by Gregory P. Smith <[EMAIL PROTECTED]>:


--
versions: +Python 2.6, Python 3.0

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-03-17 Thread Gregory P. Smith

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

i'll take a look at this during the sprint.

--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-01-16 Thread Andrew Ferguson

Andrew Ferguson added the comment:

The idea of dynamic typing it seems quite heavy to me, but I'm not a
Python hacker, so I don't know what's the norm.

Notice that os.stat() does "PyInt_FromLong((long)st->st_uid)" on the
stat structure's st_uid field. On my platform (OS X 10.4), st_uid is
defined as a uid_t type.

So maybe os.stat() has the answer: ignore the signed vs. unsigned int
problem and just use a long. The actual chown() call in posix_chown()
casts the uid variable to a (uid_t) anyway. GCC doesn't seem to complain
when we cast a long to an unsigned int, even.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-01-16 Thread Sean Reifschneider

Sean Reifschneider added the comment:

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.

Added file: http://bugs.python.org/file9182/posixmodule-chown-dynamic.patch

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-01-15 Thread Martin v. Löwis

Martin v. Löwis added the comment:

I believe that patch would break on a system where uid_t is a 64-bit
value, yet unsigned int is 32 bits.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-01-15 Thread Sean Reifschneider

Changes by Sean Reifschneider:


_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1747858] chown broken on 64bit

2008-01-15 Thread Sean Reifschneider

Sean Reifschneider added the comment:

It seems like the problem here is that chown is defined to take -1 for
the arguments, where the underlying platform may define chown taking
unsigned uid/gid.

I think in the short term we will need to apply a patch like one of the
ones included here, but in the long term maybe something like
"chown(path, uid = None, gid = None)"?  With "chown(path, gid = 69)". 
Does it make sense to use None instead of -1 in the long term?

--
keywords: +64bit, patch
nosy: +jafo
type:  -> behavior

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com