I have a full strace at
http://pimlott.ne.mediaone.net/~andrew/tmp/smbclient.trace .
> Theory 2.) The failure is caused by a period of inactivity.
>
> This may indeed be a piece of the puzzle, and seems to be one of the more
> popular notions going around. However, in the same laboratory setup
> mentioned above, I disconnected the client machine overnight, and it was
> still working properly upon re-connection the next day.
That's because nobody else was there overnight, to prompt the NT box to drop
your connection. At least, that's my hunch.
> Theory 4.) The failure has something to do with the DEBUG option in the
> source code.
>
> The theory goes that the DEBUG option will work, but if it is turned off,
> that is where the problem starts. Something to do with attempting to write
> out error messages. I haven't had the opportunity
> to observe this directly, but it is an interesting theory.
You can see this directly from the strace I posted. The faulty debug output
goes to fd 1, which is variously opened and closed as the program runs
(since smbmount initially closed it). Finally, this results in an uncaught
SIGPIPE.
This is due to a simple typo or thinko in the preprocessor directives. See
my other message. When corrected, smbmount works works with the default
#define's.
(BTW, in one case there is an EPIPE on a write to this fd, without a
SIGPIPE. Is that ok?)
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/