Is there a way to NOT get FUSE callbacks for operations triggered by 'same' process?

[mixtly]

Use case: I'm implementing solution like Dropbox and server-timeline is observed for remote changes:

1. I get an event that folder has been deleted on remote
   
2. Do something like [NSFileManager removeItemAtPath:path]
   
3. this calls FUSE callbacks to delete a file and fuse does that recursively for all subfolders and files which is not what I want because I don't whether FUSE callbacks are fired by my process or by user action
   

I could just update the local model and let finder and others update when they figure out something changed, but no FSEvents would be fired in that case so other clients would not be able to update immediately.

Is there a rule-of-thumb on how to workaround this?

[Sam Moffatt]

Hi there,

Keep in mind that Dropbox sync's changes directly to the local filesystem versus providing a layer for syncing on top. If you're looking to do something like that then you might want to look into taking that pathway as well. Doing this alleviates you from doing a whole bunch of messy IO operations that can come up in FS development and quirky behaviours of various tools. Instead you can notice the change, set a timer to make sure the file is stable and then pick up a consistent copy of the file to sync.

If you trigger a user space action, it's going to propagate to the kernel and then back to your filesystem. I don't see how you could block it or why anything would have the context to know what you're doing. You could just handle that this is something that is going to happen and honor the deletes quickly. There is an API somewhere that should let you invalidate the cache to flag that the underlying FS has changed and the kernel should look again.

Cheers,

Sam Moffatt
http://pasamio.id.au

--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-group+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mixtly]

Thank you Samuel,

do you have any idea where I could find that API which would let me invalidate the cache so that kernel should look again? I tried googling it but without any success :(

But I guess that would be a hacky solution anyways.

Sam Moffatt
http://pasamio.id.au

To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.

[Sam Moffatt]

I think fuse_purge_np() is what you’re looking for though I’m not quite 100% on that, someone else might be able to clarify.

Sam Moffatt
http://pasamio.id.au

To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-group+unsubscribe@googlegroups.com.

[barry....@primebase.org]

You can call fuse_get_context() which returns a 'struct fuse_context' , in there you will find a 'pid' which contains the process id of the calling process. You can use that to see if the callback was triggered by your own process.