[Gmailagent-devel] Re: libgmail bugfix release 0.1.3

[Richard J. <jo...@gm...>]

On 9/22/05, Stas Z <sta...@gm...> wrote:
> On 9/21/05, Sebastien Delafond <sde...@gm...> wrote:
> > Unfortunately this doesn't fix gmailfs: I am still getting errors on
> First of all, I know nothing about gmailfs, but I see some trouble spots.
>
> [...]
> >   ~ # sudo touch /mnt/test
> >   Empty account
> >   Traceback (most recent call last):
> >     File "/usr/share/gmailfs/gmailfs.py", line 1094, in getinodemsg
> >       return thread._messages[len(thread._messages)-1]
> >   IndexError: list index out of range
> Just guessing here, but I suspect this is the GmailThread._messages attri=
bute.
> If so it's better not to use  attributes directly but to use the API
> Further more if indeed GmailThread._messages is used, this class
> hasn't changed since
> libgmail version 0.1.0.
>
> [....]
> > And then listing it doesn't yield an exception, but something even
> > weirder:
> >
> >   ~ # sudo ls /mnt/bar
> >   Empty account
> Yet another result of accessing class attributes directly rather then
> through an API.
> It's part of a exception catch I added to test for empty message threads.
>
> I suspect because gmailfs interacts with the internal message threads
> rather then
> through an API, it gets into trouble because there are changes to these i=
nternal
> class attributes.
>
> >
> > Has there been an API change somewhere, among all those
> > bugfixes/security fixes ?
> Changes yes, to an API no.
>
> I hope richard can comment on this, because I don't know how gmailfs (ab)=
uses
> libgmail.
>

Hi Stas,

You are quite correct I shouldn't be messing with the internal class
attributes, however I don't think this is the core problem here
(although it doesn't help).

If you look at the GmailSearchResult initialisation method below:

class GmailSearchResult:
    """
    """

    def __init__(self, account, search, threadsInfo):
        """

        `threadsInfo` -- As returned from Gmail but unbunched.
        """
        #print "\nthreadsInfo\n",threadsInfo
        try:
            if not type(threadsInfo[0]) is types.ListType:
                threadsInfo =3D [threadsInfo]
        except IndexError:
            print "Empty account"
            threadsInfo =3D [ ['']*13 ]
        self._account =3D account
        self.search =3D search # TODO: Turn into object + format nicely.
        self._threads =3D []
        #print "\nthreadInfo\n",pprint.pprint(threadsInfo)
        ####### debug code #########
##        f =3D open('out.txt','w')
##        pprint.pprint(threadsInfo,f,4)
##        f.close()
        #############################
        for thread in threadsInfo:
            self._threads.append(GmailThread(self, thread))


Based on the error message "Empty Account" you seem to be assuming
that threadsInfo[0] will be an illegal index only when the account is
empty.  In fact there appears to be a much more common reason for
threadsInfo to be empty, this seems to occur (based on my limited
testing) when the query returns no results.  By catching the error in
the way you are doing and filling threadsInfo with some value to
prevent it being empty you are causing len on a GmailSearchResult to
return 1, when really there were no results.  The gmailfs errors occur
when after checking the len and finding it is one I then grab some
stuff on the assumption that there are results when really there are
none.  If you can make the len return 0 when there were no results
(which seems to make sense) then the other gmailfs problems should go
away (although I am still being silly and accessing internal
attributes, I couldn't find an API supported way of directly indexing
particular thread and message numbers, please tell me if I'm missing
something).

Regards,
Richard.