MacOS Extension Carbon.File.FSCatalogInfo file sizes should be UInt64?

Discussion in 'Python' started by donbro, Oct 31, 2005.

  1. donbro

    donbro Guest

    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
    donbro, Oct 31, 2005
    #1
    1. Advertising

  2. donbro

    Kevin Walzer Guest

    Re: MacOS Extension Carbon.File.FSCatalogInfo file sizes should beUInt64?

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    donbro wrote:
    | 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
    |
    You're most likely to get a good answer to this question on the
    MacPython mailing list--give that a try if you don't get a response here.


    - --
    Cheers,

    Kevin Walzer, PhD
    WordTech Software - "Tame the Terminal"
    http://www.wordtech-software.com
    sw at wordtech-software.com
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (Darwin)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFDZmj8JmdQs+6YVcoRAtkTAJ9CEYbIRy6VLY7qp304JPmcl+iXUQCdHTMT
    KmJljW7loFJNKFsjFkB2aNA=
    =vEVV
    -----END PGP SIGNATURE-----
    Kevin Walzer, Oct 31, 2005
    #2
    1. Advertising

  3. donbro

    donbro Guest

    Kevin,

    Thanks for the tip. I'll post this to the pythonmac-sig mailing
    list.

    Don
    donbro, Nov 1, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    336
    fortepianissimo
    Jan 21, 2005
  2. Abhilash
    Replies:
    0
    Views:
    269
    Abhilash
    Feb 7, 2007
  3. Abhilash
    Replies:
    0
    Views:
    281
    Abhilash
    Feb 7, 2007
  4. kitty
    Replies:
    3
    Views:
    489
    Joe Kesselman
    Jan 7, 2007
  5. msmucr
    Replies:
    3
    Views:
    474
    msmucr
    May 15, 2012
Loading...

Share This Page