[fuse-devel] AVFS (but not only) + FUSE : access() returns W_OK, but opening r+ fails

[Giuseppe B. <giu...@gm...>]

Hello all,

I've come across an odd bug while using AVFS (the A Virtual File System FUSE
originated from) 0.9.7 (self-compiled) with FUSE (fusermount 2.6.3, kernel
module from either a custom-built 2.6.21 or the stock debian 2.6.18 and
2.6.20 kernels).

I've discovered the bug because amarok wouldn't display any tags from the
music files played from virtual directories mounted from .zip files:
although the music files themselves play correctly (most of the time), no
tags (or expected length) are available, even though copying those files to
a 'regular' filesystem magically restores tags etc.

Some internet inquire and a brief bug-report-centered exchange with the
taglib developer shows that avfs is not the only FUSE-based filesystem that
suffers from this bug, smbnetfs for example is affected too.

Basically, there is an inconsistency between what's reported by access() and
what can be obtained by fopen(). A small C code such as the following:

#include <stdio.h>
#include <unistd.h>

char name[1024] = "/path/to/some/fuse/mounted/fs/filename.ext"

int main(void) {
        FILE *ptr = NULL;
        printf("%d\n", access(name, F_OK));
        printf("%d\n", access(name, R_OK));
        printf("%d\n", access(name, W_OK));
        printf("%d\n", access(name, X_OK));

        printf("Pointer before: %#p\n", ptr);
        ptr = fopen(name, "r");
        printf("Pointer after open r: %#p\n", ptr);
        if (ptr)
                fclose(ptr);
        ptr = fopen(name, "r+");
        printf("Pointer after open r+: %#p\n", ptr);
        if (ptr)
                fclose(ptr);
}

returns the following:

0
0
0
-1
Pointer before: (nil)
Pointer after open r: 0x804a008
Pointer after open r+: (nil)

for a file mounted from a virtual folder originating from an archive.

So, even though access() reports that it's ok to open the file for reading
and for writing, trying to open it read/write fails.

I've initially suspected a bug in AVFS, but a quick look at the code seems
to suggest that AVFS might be doing the right thing (returning -EACCES when
bit 2 in the mode is set). This, plus the fact that it also happens with
other FUSE filesystems, makes me suspect that FUSE might be the culprit,
but OTOH I can't see anything obviously wrong in the FUSE code either.

So I decided to pass the question over to more experienced people: is it a
FUSE or an AVFS (and coincidentally smbnetfs) bug? In either case, how
could it be fixed?






-- 
Giuseppe "Oblomov" Bilotta