If my read of the extension source (Mac/Modules/file/_Filemodule.c) is
correct, the parameter sizes specified for data and resource file sizes
are UInt32 where they should be UInt64.
In both OS9 and OSX Carbon, the MacOS File Manager (Files.h) uses
UInt64 values for data and resource filesizes.
Testing Python 2.3 and 2.4.2 on MacOS 10.3 returns 0L for the file size
values and correct values for other elements such as parentDirID:
>>> fsRef = FSRef('LICENSE')
>>> catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L)
>>> catinfo.dataPhysicalSize
0
>>> catinfo.parentDirID
2026177
in Files.h, both OS9 and OSX Carbon, the elements are UInt64:
struct FSCatalogInfo {
[...]
UInt64 dataLogicalSize;
UInt64 dataPhysicalSize;
UInt64 rsrcLogicalSize;
UInt64 rsrcPhysicalSize;
[...]
}
in _Filemodule.c the spec looks to be 32 bit:
static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoObject
*self, void *closure)
{
return Py_BuildValue("l", self->ob_itself.dataLogicalSize);
}
I have, perhaps naively, just changed my local copy to use a BuildValue
parameter of "L" instead of "l" for each of these get and set methods
and this has survived my initial testing:
static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoObject
*self, void *closure)
{
return Py_BuildValue("L", self->ob_itself.dataLogicalSize);
}
But my questions are:
Has anyone else seen this?
Does this seem like the right fix?
There is another routine in _Filemodule.c: FSCatalogInfo_tp_init() that
also seems to hold information relevant to parameter size. Should this
be changed as well?
If this is a bug, what's the best procedure to report this?
Sourceforge? This mailing list?
I'm porting a MacOS9 application from C++ to python and I expect to be
seeing a lot of these python macintosh filesystem extensions in the
near future!
Thanks for any help
Don
--
http://mail.python.org/mailman/listinfo/python-list
