>>SMB protocol could be viewed´/interpreted as a LAN based interface into the server file system. Server settings like Oplocks/Caching may throw a wrench into expected operations.
>
>That's the problem of them windowses.



>The SMB stands for Samba, which is a unix protocol and does what you say, provide file access (and locking) through a network regardless of the OSes on either end. So a *x can talk with a windows can talk with a mac, as long as they stick to the protocol.

Directly opposite to the way I remember: Samba was the Unix implementation of SMB offering the same services through an offering with identical consonants for *x, as SMB had become the de-facto standard on PC hadware. MS had NetBios first defaulting to run over NetBEUI (AFAIR from WfW up to NT4 and W98, W2K I remember running here over TCP/IP but uncertain if I had to set it myself and very uncertain about the DOS drivers), which was ok on networks up to the # of human appendages.

>
>Of course, the Redmondlians never forgot the embrace-extend-kill strategy, so when they joined the SMB standard it had to be good for a while, but then they had to extend it (the oplocking, caching etc), allegedly to optimize it but the end result is that the database model with isam tables in a file sharing environment is practically dead on windowses. Though it would be interesting to test what happens with the faulty SMB2 and SMB3 if the file server is a linux box. Perhaps then it would just work, eh?

Probably, but first Sambas had real problems with locking - which might have been a problem due to "sporadic" MS docs, which was one area MS was pressed, but I do not know if that was the source of that specific problem.