[Pythonmac-SIG] In Mac/Modules/file/_Filemodule.c dataLogicalSize, etc., should be UInt64 ("L")

Laura McColm donbro at mac.com
Tue Nov 1 02:26:27 CET 2005


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 



More information about the Pythonmac-SIG mailing list