Is there an osxfuse equivalent for the fuse call fuse_lowlevel_notify_inval_entry

[meg75]

I don't see the fuse call fuse_lowlevel_notify_inval_entry in any of the low level files.  Is there another way to accomplish the same in osxfuse?

[Benjamin Fleischer]

There is another way. It's called fuse_purge_np. It will purge the kernel caches for the specified file.

fuse_lowlevel_notify_entry was added in libfuse 2.8.0. Currently OSXFUSE is shipping with libfuse 2.7.3.

Am 21.02.2013 um 06:56 schrieb meg75 <megr...@socket.net>:

I don't see the fuse call fuse_lowlevel_notify_inval_entry in any of the low level files.  Is there another way to accomplish the same in osxfuse?

--
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-grou...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[meg75]

Thanks, but I am seeing crashes when I use that call.  Here is some crash info:

Thu Feb 21 11:11:01 2013

panic(cpu 1 caller 0xffffff7f825a3849): "OSXFUSE: Attempted to unlock non-locked recursive lock."@/Users/benjamin/Documents/Projekte/OSXFUSE/Repositories/osxfuse/kext/fuse_locking.c:477

Backtrace (CPU 1), Frame : Return Address

0xffffff800808bbe0 : 0xffffff8000a1d626 

0xffffff800808bc50 : 0xffffff7f825a3849 

0xffffff800808bc70 : 0xffffff7f825a4c31 

0xffffff800808bcc0 : 0xffffff7f8259cbcf 

0xffffff800808bd10 : 0xffffff8000b2055d 

0xffffff800808bd60 : 0xffffff8000b11ec4 

0xffffff800808bdd0 : 0xffffff8000b08459 

0xffffff800808be20 : 0xffffff8000d4ae63 

0xffffff800808be50 : 0xffffff8000d77ae3 

0xffffff800808bf50 : 0xffffff8000de182a 

0xffffff800808bfb0 : 0xffffff8000aced33 

      Kernel Extensions in backtrace:

         com.github.osxfuse.filesystems.osxfusefs(2.5.4)[2A591BB7-069D-966B-18F7-0154EF58C0E0]@0xffffff7f8259c000->0xffffff7f825b4fff

[Benjamin Fleischer]

Thanks for reporting the panic. The issue should be fixed in commit https://github.com/osxfuse/kext/commit/c9869588305d58d2c5f18dc72c99f8576ec1d483.

[meg75]

Thanks.  No more panic.

I am wondering about this call.  I have a test program running a osxfuse filesystem so I can play around with this to see how it works.  From my command line I can make changes to my filesystem.  I set up a folder (Folder1) in the root directory and did a ls-l.  Looks good.  I then made the purge call and it returned 0 (which I assume means no error).  I then changed the folder to be a file.  The next ls -l command returned this: ls: Folder1: Input/output error.  I would have thought the purge command would have erased any prior knowledge of the entry.  Am I still missing something?  Thanks...

[Benjamin Fleischer]

Let me start by saying that changing something behind OSXFUSE's back, so to speak, can cause issues when using kernel side caching. It can be tricky to make everything behave correctly. The problem here is that OSXFUSE does not know about the external change.

fuse_purge_np purges the vnode's ubc and attribute caches, but it does not erase knowledge about the vnode itself (node name cache). When changing the type of the file/folder it needs to be removed from the name cache, too. To test this try running your file system with option novncache.

[meg75]

Thank you for sharing that information.  I tried the option novncache, but did not see any difference.  I still get the same error when using the ls -l command.  In addition, if I mess around with things enough, I can get this from the ls command: ls: Folder1: Device not configured.  I don't think that the novncache option was responsible for that error.

Is there anything else I could try?  I would think a networked filesystem or the like would have to deal with things like this - having things changed "behind OSXFUSE's back" as you say.  Thanks for the help...

[Graham Perrin]

On Friday, 22 February 2013 16:21:29 UTC, meg75 wrote:

… a networked filesystem or the like … 

Here it may be appropriate to quote from the old FAQ for MacFUSE: 

>> … itself isn't a distributed remote file system! It's a

>> mechanism for building arbitrary file systems. If you

>> change things "externally" to MacFUSE (like, a file on the

>> remote server in the case of sshfs), in general, things

>> need to be done proactively to tell MacFUSE that something

>> has changed, otherwise you'll get such "incorrect"

>> behavior. In particular, sshfs isn't meant to replace

>> things such as NFS, AFP, and SMB …

– <http://code.google.com/p/macfuse/wiki/FAQ>, <https://diigo.com/0xx5r> for highlights.