Greetings All!
I am moving a document management app from C++/OS9 to Python/OSX Carbon
and I am delighted with the functionality I'm finding in the MacOS specific
extension modules. Just what I needed! But I was dismayed to be unable to get
anything but the value 0L for the file sizes (dataLogicalSize,
dataPhysicalSize, rsrcLogicalSize, rsrcPhysicalSize) in the catinfo structure
returned by FSRef.FSGetCatalogInfo().
Python 2.3 and 2.4.2 (and 2.5!) on MacOS 10.3.9 returns 0L for the
various file size
values and correct values for other elements in the structure such as
parentDirID:
>>> fsRef = FSRef('LICENSE')
>>> catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L)
>>> catinfo.dataPhysicalSize
0
>>> catinfo.parentDirID
2026177
I'm new to the mechanisms inside the extensions themselves, but it looks to me
that the routines building the return values (such as
FSCatalogInfo_get_dataLogicalSize() in source file
Mac/Modules/file/_Filemodule.c) should specify UInt64 instead of UInt32.
static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoObject
*self, void *closure)
{
return Py_BuildValue("l", self->ob_itself.dataLogicalSize);
}
Should change the "l" to "L" in each of the four routines:
static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoObject
*self, void *closure)
{
return Py_BuildValue("L", self->ob_itself.dataLogicalSize);
}
Works fine now:
manny:~/dev/python/dist/src donb$ ./python.exe
Python 2.5a0 (#1, Oct 31 2005, 01:18:46)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Carbon.File import FSRef
>>> fsRef = FSRef('LICENSE')
>>> catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L)
>>> catinfo.dataLogicalSize
13423L
>>> ^D
But my questions are:
Has anyone else seen this? The os.stat() function returns a "unix-like" file
size, i.e. data fork only, and I needed the "Mac-like" size
(catinfo.dataLogicalSize+catinfo.rsrcLogicalSize)
Does this seem like the right fix? Am I catching all the implications?
There is another routine in _Filemodule.c:
static int FSCatalogInfo_tp_init(PyObject *_self, PyObject *_args, PyObject
*_kwds)
{
static char *kw[] = {
[...]
"dataLogicalSize",
"dataPhysicalSize",
"rsrcLogicalSize",
"rsrcPhysicalSize",
[...]
, 0};
if (!PyArg_ParseTupleAndKeywords(_args, _kwds,
"|HhllO&O&O&O&O&llllllb", kw, &((FSCatalogInfoObject
*)_self)->ob_itself.nodeFlags,
[...]
This also seems to hold information about parameter size. Should these four
"l"'s be changed as well? (My intuition/luck is running out here, guess I'll
have to read up on what all of these mechanisms are actually doing :-)
If this is a good patch, what's the best place to submit this? Sourceforge?
This mailing list?
Since I'm porting a MacOS9 application from C++ to Python I'm prepared to spend
some time with Python and the extension mechanisms in the
near future!
Thanks for any help
Don
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
