Of course, the timeout is by design. MacFUSE file systems, although
they are "regular" programs, can adversely affect the system by
hanging, crashing, or otherwise misbehaving. This is because so many
other programs and system components interact with a file system. The
problem is especially severe on Mac OS X, where the entire user-
visible interface can apparently hang. It's a bit better on Leopard as
compared to Tiger. On Leopard, the Finder is nicer in terms of not
hanging many other things if a single file system goes awry.

By default, MacFUSE (the kernel part, specifically) *will* indeed
terminate the kernel-user connection (which in turn will terminate
your user-space file system work loop, which in turn will seem to
"kill" your program) if the user part hasn't responded for
FUSE_DEFAULT_DAEMON_TIMEOUT seconds. (Defaults to 30 seconds on Tiger,
60 seconds on Leopard.) You can control the timeout value on a per-
mount basis through the "daemon_timeout" argument.

Amit

On Feb 5, 3:26 pm, David <[EMAIL PROTECTED]> wrote:
> On Jan 27, 1:06 pm, Jeff Bone <[EMAIL PROTECTED]> wrote:
>
> > Okay, I solved the "Symbol not found: _iconv" problem.  I downloaded
> > a fresh (2.0) Python FUSE bindings and added a line to setup.py as
> > follows:
>
> >    libsonly.append("pthread") # <-- existing line
> >    libsonly.append("iconv") # <-- new line
>
> Thanks, Jeff, that solved my problem!  You're a rock star!
>
> > However, now when I run gmailfs I'm getting numerous lines of the form:
>
> This one I don't know about.  I'm not using gmailfs.
>
> I have a new problem.  To test the robustness of my new Python file
> system, which is a network file system, I tried disconnecting my
> network during a file transfer ("cp foobar /tmp/").  After about 30
> seconds of no network, my Python daemon stopped abruptly, and I saw
> the following error message in Terminal:
>
> cp: foobar: Socket is not connected
>
> I tried wrapping a try clause around the code being executed, but it
> didn't catch any exception ('SOCKET ERROR' was never printed):
>
>                    try:
>                         key.get_contents_to_filename(localPath,
> None,  callBack)
>                     except :
>                         print 'SOCKET ERROR'
>
> This is bad news if my Python file system just gives up when there's a
> network failure.  Is there any way I can catch this condition instead
> of the whole program dying?  Is there a MacFUSE command line option I
> should be using?  I'm using MacFUSE-Core-10.5-1.3.1.
>
> Thanks,
> David
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to