Yes, from user-space. For example, if getattr() cannot return
normally because of a network error (like the network has gone down),
I can handle the error (I return -E_NETDOWN). MacFuse doesn't mind
this, and it waits patiently for the network to come back up (as long
as I continue to redirect fs calls to error handlers). However, if
I try and unmount the volume, Finder beachballs...unless I use the -
onovncache option. From what I can tell, using this option
automatically purges new entries in the vncache, before any lookups
can take place. I *want* to use the vncache, for performance reasons,
but if I am right about what -onovncache does, purging entries on
demand during this error condition should fix my problem with Finder.
I try to do this in getattr()'s error handler, calling
fuse_purge_path_np with getattr()'s path argument, but I get the
aforementioned segfault. Is there another avenue for purging the
vncache from user-space?
n.b. In some older versions of fuse, fuse_invalidate() purged a
particular path's inode from the cache. In the current version, the
function is marked as "obsolete" and just returns E_INVAL. It doesn't
seem like its functionality has been replaced by anything, however.
On Feb 14, 1:16 am, Amit Singh <[EMAIL PROTECTED]> wrote:
> By the way, where are you calling this function from? Hopefully from
> within the user-space file system that's responsible for "path" (and
> not from a different program altogether). Is that the case?
>
> Amit
>
> On Feb 13, 8:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > Is this function known to work? It seems like a rewrite of the now-
> > obsolete fuse.c/fuse_invalidate() and appears to try and flush entries
> > from the vnode cache, among other effects, but when I call it with a
> > valid path, like "/", I get a segmentation fault. Here's my code
> > (using python bindings):
>
> > <code>
> > // python function
> > def purgeName(path):
> > return FusePurgeName(path)
>
> > // C function
> > static PyObject *
> > FusePurgeName(PyObject *self, PyObject *args)
> > {
> > char *path;
> > PyObject *ret;
> > int err;
>
> > PyArg_ParseTuple(args, "s", &path);
> > printf("%s\n", path);
> > err = fuse_purge_path_np(path);
> > // segmentation fault before it returns
> > printf("%i\n", err);
> > ret = Py_BuildValue("i", err);
> > return(ret);}
>
> > </code>
>
> > I'm admittedly rusty with C, so I could be passing the path string
> > incorrectly, but the printf looks correct, and PyArg_ParseTuple is
> > guaranteed to null-terminate any strings.
>
> > If I set path to "" or NULL, the behavior is correct (i.e., it returns
> > with an errno). Any idea why it faults when I pass it a path string?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"macfuse-devel" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/macfuse-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
