By the way, is this function what was referred to by the line, "New
mechanism for per-file buffer cache purging" in the changelog for
v1.0.0? I didn't see anything else that fit the description, which is
why I tried using it in the first place.
On Feb 14, 2:21 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
