Hi all, This question has come up many times before in a number of guises. But I do not believe that it has ever been answered satisfactorily.
This may well reflect fundamental difficulties in the CIFS protocol However, recent incarnations of Windows Server seem to handle the problem better possibly due to tweaks in the underlying TCP/IP stack vis-a-vis Linux. At the end of the day, a centralised/shared file system should be immune to client misbehaviour. While file corruption by a misbehaving client with write access is always a possibility. Surely it is reasonable that a file should not be left locked indefinitely by a client that has long since departed the scene. Suggested solutions usually revolve around: 1. Client configuration tweaks. 2. Samba's "Reset on Zero VC" option in smb.conf. My response to these is that: 1. A server should not have to depend on well-behaving clients to maintain basic file system integrity. 2. "Reset on Zero VC" only helps in the case where the disconnected client actually reconnects. But what if a client suddenly disconnects due to a crash, power outage or careless disconnect? What if the client stays disconnected indefinitely e.g. laptop has been whipped out and gone off site? In these situations, a server administrator needs to be on standby. And straggling locks can be removed manually by: 1. Identifying them using the smbstatus utility 2. Killing the relevant server process. But this can become extremely tedious in busy ad hoc networks with mobile users So can someone please advise me why it is not possible for Samba to: 1. Identify obvious long term client disconnects e.g. by polling every five minutes. 2. Automatically remove any locks still held by such clients. Hope I am making some sense here and haven't missed something obvious. TIA rvjcallanan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
