[karmic] getxattr in python-fuse does not respect size=0 API

[Facundo Batista]

Binary package hint: python-fuse

The getxattr function in python fuse does not respect the API regarding size=0.

As the manpage says...

"""
       An empty buffer of size zero can be passed into these calls to return the current size of the named extended
       attribute, which can be used to estimate the size of a buffer which is sufficiently large to hold the value associ‐
       ated with the extended attribute.
"""

However, it currently only checks if the returned string size is bigger than the asked-for size (and as this size is sometimes 0), you just get a broken behaviour (it even generates the incorrect error).

Both issues are fixed in the pach I'm attaching.

System info:
    Ubuntu: 8.10
    Installed python-fuse: 1:0.2-pre3-9

However, note that the problem is still in python-fuse's trunk (and the diff is against that)

[Joseph Smidt (jsmidt)]

Thank you for your bug report. I have patched this package with your above patch. Here is the debdiff to close the bug. Please sponsor the upload.

[Facundo Batista (facundo)]

Note that the package has a bug that makes the patches to be applied *after* creating the binary (which is a problem when the patch applies to C stuff).

Here's the diff that fixes that:

--- python-fuse-0.2-pre3-9-ubuntu0~8.10/debian/rules 2009-02-10 09:30:38.000000000 -0500
+++ python-fuse/debian/rules 2009-02-09 15:54:49.000000000 -0500
@@ -6,6 +6,7 @@

 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/python-distutils.mk
+include /usr/share/cdbs/1/rules/dpatch.mk

 STAGING_DIR := $(CURDIR)/debian/python-fuse
 UPSTREAM_EXAMPLE_DIR := example
@@ -16,4 +17,3 @@
  cp -r $(UPSTREAM_EXAMPLE_DIR) $(STAGING_DIR)/usr/share/doc/python-fuse/examples

 clean:: unpatch

Thanks!

[James Westby (james-w)]

Hi,

Have you approached upstream about this issue?

There's a similar report from last year on the mailing list

  http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/5816

I'll happily sponsor this if you can point to some discussion of the patch
with upstream.

Thanks,

James

[Facundo Batista (facundo)]

James Westby escribió (el 16/02/09 20:56):

> Have you approached upstream about this issue?
>
> There's a similar report from last year on the mailing list
>
> http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/5816
>
> I'll happily sponsor this if you can point to some discussion of the patch
> with upstream.

Don't know how to approach them... they seem to don't have a bug tracker, and in the list it's exactly the same bug
reported.

Regards,

--
. Facundo
.
Canonical - Online Services

[James Westby (james-w)]

On Tue, 2009-02-17 at 12:17 +0000, Facundo Batista wrote:
> James Westby escribió (el 16/02/09 20:56):
>
> > Have you approached upstream about this issue?
> >
> > There's a similar report from last year on the mailing list
> >
> > http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/5816
> >
> > I'll happily sponsor this if you can point to some discussion of the patch
> > with upstream.
>
> Don't know how to approach them... they seem to don't have a bug tracker, and in the list it's exactly the same bug
> reported.

Well, sending your patch to the mailing list may well get more response
than when that person just sent a bug report, could you try that please?

Thanks,

James

[Facundo Batista (facundo)]

I sent the following mail twice (Feb 25th and 27th) from my gmail address, never got any answer, and it even seems that they didn't get into the list, as they're no in the SF archive.

------------------- 8< ---------------------------------------
Hello!

I found that the getxattr function in python fuse does not respect the
API regarding size=0.

As the manpage says...

"""
      An empty buffer of size zero can be passed into these calls to
return the current size of the named extended
      attribute, which can be used to estimate the size of a buffer
which is sufficiently large to hold the value associ‐
      ated with the extended attribute.
"""

However, it currently only checks if the returned string size is
bigger than the asked-for size (and as this size is sometimes 0), you
just get a broken behaviour (it even generates the incorrect error).

This is the very same problem described in this old post to this same list:

 http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/5816

The news is that I created a patch to address this issue (we tested
this patch at work, and works ok for us).

The patch is here:

 http://launchpadlibrarian.net/22018646/fuse_getxattr.patch

(it's on a Launchpad bug, #325860)

Regards,
------------------- 8< ---------------------------------------

They don't have a bug tracker, so don't know what else I can do, :(.

[Iain Lane (laney)]

I've submitted the patch to Debian to see if the maintainer has any opinion on it. Let's defer this fix until we're sure it's correct.

[James Westby (james-w)]

This is now fixed in karmic.

Thanks,

James