[...]
You should never need to signal the smbclient process by hand -- every
retry attempt sends a signal. Take a look at smbfs/proc.c in smb_retry()
Yes. I know this.
But signaling the process by hand should not IMO oops any processing which
may be sleeping waiting for smbfs...
One can argue only root can send smbclient a this signal, and root and crash
the system trivially anyhow...
I added some debugging printfs to smbclient that might help. You should
see it wake up and attempt to open the sockets every time smbfs enters
the retry code.
Umm... nope. It enters the retry code and only sometimes does it send
smbclient a signal. The times it does - everything works. But when it
doesn't - well, the connection is closed so obviously things don't work.
Open files can't persist from connection to connection -- the server
resets them each time. This is handled in smbfs by setting the open flag
to server->generation, which is incremented each time.
Umm.. perhaps I misunderstand. What I was wondering though, was that if I
open a file RW, will the server time out the connection - and if so, how is
this dealt with.
Even if the file is opened RO, and the connection is closed, and the kernel
does initial a transparent reconnect - how do we know the data in the file
we apparently have open is still correct?
Nether of these two points really matter to me, it just occurred to me that
there might be an issue here. I started looking at the SMB protocol in more
detail and have decided either I'm a thickie or the protocol is seriously
brain-damaged....
-Chris