Any way to check for or handle connection errors while manipulating files?

I have a scenario where i am writing files to a remote SMB share, however I would like to handle a case where the file writing stops and exception is raised when the connection between the two machines are interrupted for example. Currently the program just freezes and no exception is raised when this happens. I have also tried to execute the writing of file to SMB share in a separate thread and call that thread with a timeout but that doesn’t seem to work either.

Is there anyway to handle this issue?

I am connecting from a windows client to a linux server over local area network.

import time
import smbclient
import threading
import _thread

class timeout():


    def __init__(self, time):
        self.time = time
        self.exit = False

    def __enter__(self):
        threading.Thread(target=self.callme).start()

    def callme(self):
        time.sleep(self.time)
        if self.exit == False:
            _thread.interrupt_main()  

    def __exit__(self, a, b, c):
        self.exit = True


with timeout(20):
    try:
        while True:
            time.sleep(0.3)
            try:
                smbclient.stat(
                    somefilehere)
            except Exception as e:
                print(e)
            print("done inner")
    except KeyboardInterrupt:
        print("done outer")

[jborean93]

Scenario 3 is a connection timeout which we currently have set to 60 seconds. There doesn’t seem to be a way to define this in the ClientConfig() globally for the high level API but it is a supported kwargs under connection_timeout. I’m surprised it’s only 25-30 seconds as the default is 60.

Scenario 4 looks to be a critical failure when the client does not receive a FIN or ACK from the server causing it to always see the connection as online. I’ve been able to replicate this behaviour for both blocking and non-blocking sockets when turning a libvirt interface off. All the calls, sock.send(), sock.recv(n), and select([sock], [], []) all hang indefinitely even though the interface is no longer present. I have no idea why it’s still there as the actual network interface is no longer present on the client but I don’t see any way around this. It does sound like we need a more sane timeout when sending and waiting for a response but the way the current API is set out makes that hard to inject. Potentially I need to enable TCP Keep-Alive but that does not seem to be portable across platforms so I’ll have to keep this in mind for future releases.

I appreciate the time and effort you’ve put into testing all this and I’m fairly confident the code in the PR helps with normal socket shutdown and closures from both the client and server side. It seems like there is still some more work that can be done to handle abnormal interrupts which I’ll try to look into in the future.

[zuroh]

Thank you! I’ll test it soon as I’m free and get back to you with the results.