mukulyadav49 / macfuse

Automatically exported from code.google.com/p/macfuse
Other
0 stars 0 forks source link

MacFUSE: OUCH! daemon did not give fh (type=2, err=2) and other events in system.log #232

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
1) My system apparently stopped (clock in menu bar stopped) for a few minutes. 

2) When it resumed, there remained the mount point for the 
one volume that I had mounted via MacFUSE/MacFusion/EncFS.plugin
but the file system was not present at the mount point. 

3) I quit from various applications, removed the mount point (clicked Eject in 
Finder sidebar), re-mounted the volume. 

Re: the system.log entries below, please, can you offer advice?

AFAIR the last significant actions before the issue occurred were: 

a) using Default Apps <http://www.rubicode.com/Software/RCDefaultApp/>

b) I clicked the MIME Types tab (the resulting list usually takes some time to 
present)

c) a peripheral FireWire disk, which would normally spin during that routine, 
was probably _not_ spinning before I clicked 'MIME Types'.

From system.log
---------------

Jul  1 13:23:27 grahamperrin DirectoryService[104]: Failed Authentication 
return is being delayed due to over five recent auth failures for username: 
root.
Jul  1 14:07:18 grahamperrin kernel[0]: MacFUSE: OUCH! daemon did not give fh 
(type=2, err=2)
Jul  1 14:07:18 grahamperrin kernel[0]: MacFUSE: failed to get fh from strategy 
(err=2)
Jul  1 14:13:48 grahamperrin kernel[0]: MacFUSE: unknown response from alert 
panel (kr=0, rf=-1876398048)
Jul  1 14:13:48 grahamperrin KernelEventAgent[80]: tid 00000000 received 
unknown event (33)
Jul  1 14:13:59 grahamperrin kernel[0]: MacFUSE: OUCH! daemon did not give fh 
(type=2, err=57)
Jul  1 14:13:59 grahamperrin KernelEventAgent[80]: tid 00000000 received 
VQ_DEAD event (32)
Jul  1 14:14:00 grahamperrin kernel[0]: MacFUSE: OUCH! daemon did not give fh 
(type=2, err=5)
Jul  1 14:14:02 grahamperrin KernelEventAgent[80]: tid 00000000 received 
VQ_DEAD event (32)

From console.log
----------------

2007-07-01 14:00:15.632 Chicken of the VNC[25617]   shift(r/g/b) = (16/8/0)
rfbPixelFormat redMax = 255
rfbPixelFormat greenMax = 255
rfbPixelFormat blueMax = 255
2007-07-01 14:09:23.910 Mail[12174] Container frame: {{551, 0}, {852, 916}}
2007-07-01 14:09:23.911 Mail[12174] View: <NSScrollView: 0x1710beb0>
2007-07-01 14:09:23.911 Mail[12174]    frame: {{0, 0}, {852, 916}}

##

The string 

> MacFUSE: unknown response from alert panel 

also appears in MacFUSE issue 227 
<http://code.google.com/p/macfuse/issues/detail?id=227> 
but in this instance the log entry is preceded by other MacFUSE-related 
entries. 

##

MacFUSE 0.4.0
MacFusion nightly 20070627 revision 279
EncFS.plugin 0.2.0

At the time of the issue: just one MacFUSE/MacFusion-mounted volume, 

FSType = EncFS; 
StoredObject = {
    advancedOptions = ""; 
    mountOnStartup = 1; 
    name = "gjp22-private"; 
    storagePath = "~/Documents/.encfs"; 
}; 

Original issue reported on code.google.com by grahampe...@gmail.com on 1 Jul 2007 at 1:44

GoogleCodeExporter commented 9 years ago
It is possible for the Finder to "hang" the user interface in such a way that 
you will not see the timeout alert 
panel from MacFUSE, which is what's happening here probably. The file system 
didn't respond for 20+ seconds, 
MacFUSE tried to throw a dialog asking you to "continue to wait", "force 
eject", etc.

The first error with the "daemon didn't give fh" is for error code 2, which 
means "no such file or directory". The 
kernel has some file open that the user-space daemon now says doesn't exist. If 
that happens, the kernel has 
no recourse but to throw an error.

Original comment by si...@gmail.com on 1 Jul 2007 at 9:34

GoogleCodeExporter commented 9 years ago
> "daemon didn't give fh" is for error code 2, which means "no such file or 
directory". 
>  The kernel has some file open that the user-space daemon now says doesn't 
exist. 

Thanks, that's most useful. 

If I find the option/opportunity, I'll debug. 

Original comment by grahampe...@gmail.com on 2 Jul 2007 at 11:49

GoogleCodeExporter commented 9 years ago
Marking as invalid since the message in system log is itself not an issue--like 
I said earlier, the message means 
the user-space file system said "does not exist" for a file that it earlier 
said exists. So something has changed 
"behind the kernel's back".

Original comment by si...@gmail.com on 13 Jul 2007 at 12:04

GoogleCodeExporter commented 9 years ago
Thanks. 

The issue (whatever it was) has not recurred. 

Original comment by grahampe...@gmail.com on 13 Jul 2007 at 5:52