From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bryan J. Smith" Subject: Re: WARNING: smbfs and locking -- POSIX v. CIFS locking, and how DOS doesn't do CIFS locking (bad things man) Date: Mon, 10 Feb 2003 18:17:42 -0500 (EST) Sender: linux-msdos-owner@vger.kernel.org Message-ID: <1044919062.3e483316a4db5@webmail.smithconcepts.com> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Return-path: In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" To: Bart Oldeman Cc: Gregor Ibic , Lista dosemu Quoting Bart Oldeman : > ok I browsed around a bit and looked at the kernel source, here's the > real answer. > Current (linux kernel 2.4.20) smbfs doesn't support locking at all. > you may look at > http://www.hojdpunkten.ac.se/054/samba > to see some experimental patches though. As Bart pointed out, CIFS locking is _not_ supported by Linux CIFS/SMB clients. CIFS/SMB locking is _foreign_ to POSIX systems, so Linux will never really support them well at all. And _no_ other UNIX flavor (that I know of) supports mounting CIFS/SMB shares anyway. Understand POSIX and CIFS are completely _different_ when it comes to file locking. POSIX is designed for UNIX clients, CIFS is designed for Windows clients. DOS clients are a different breed, but will be far more like UNIX clients than CIFS. CIFS supports byte range locks as well as stackable locks. POSIX systems do not. This makes for some interesting issues with Samba [server] emulating CIFS atop of a POSIX filesystem (although the new Samba VFS implementation is supposed to addresses), and even CIFS itself. E.g., the concept of byte range locks and stackable locks causes regular corruption on native CIFS servers (i.e. NT/2K) themselves. Hence why many CIFS clients use application-specific client-side locking (e.g., Jet for MS Access). Now let's look at DOS applications. I don't know of _any_ DOS applications that support CIFS file locking. In fact, running DOS applications on multiple systems accessing the same data over a CIFS SMB mount is almost _guaranteed_ to cause corruptions. Why? Because the CIFS client system (Windows) assumes that the application, DOS, knows how to handle its locking mechanisms when it, in fact, doesn't. So instead of getting nice, old "real" DOS style locks, which only allow one application to access a file at a time, we get CIFS "opportunistic locks" that allow multiple applications write access to the same file. Boom! Oplocks are hard coded into native CIFS servers (NT/2k), although a registry hack can disable them for the _entire_ server. Samba allows many different Oplock types and they can be specified on a per-share basis too. But I'm talking with regards to "real" CIFS/SMB clients (Windows), not "emulated" ones (Linux SMBfs). > NFS *does* support locking though. Yes, and it does it in a way that is far more "DOS-like" -- one write lock per file. > So if you see locking "working" with smbfs it is actually by accident > and not by design. Exactomundo. Linux SMBfs filesystem support is a _hack_, not something you should rely on. Don't mount NT/2K servers on Linux clients. _Always_ use the network filesystem that is "native" to the client OS. For UNIX/Linux, this is NFS. For Windows, this is CIFS/SMB. Unlike Samba on UNIX for CIFS/SMB, Windows servers don't have equivalent NFS functionality (and NFS servers available for Windows suck in my experience, although Microsoft SFU 3.0 is supposed to be better now?). So only UNIX/Linux servers make the best "cross-platform" file servers. > This means that it is very well possible to corrupt your DOS databases > if you access them via smbfs, and there's nothing that DOSEMU can do > about it. Exactomundo! And even using native Windows servers and clients would do the same! Thanx to Microsoft's "Oplocks by default". It's not so much of a problem with Linux or Samba, but the CIFS locking mechanism itself. In fact, this is where Samba shines, because it lets you disable those "multiple write locks," something DOS doesn't support (nor many Windows applications for that matter -- with Jet/Access being a rare exception), on a per-share basis. But that's only when we're talking Windows clients. If you're using Linux clients, I have two suggestions: 1. Use NFS mounts from a Linux server 2. Even better: Run multiple X-DOSEmu instances on one box, and "pump" the display to other X-Window systems #2 is the best because now you are locking _local_. It's an option _only_ available with DOSEmu on Linux. > Now, why does a Win client access the file when DOSEMU "locks" it? > This is because there actually is no lock at all! > And the other way around, what happens is that: DOSEMU tries to apply > a lock to the file, the filesystem fails, and the DOS app hence claims > that access is denied. -- Bryan J. Smith | Peace is a fruitless endeavor http://thebs.org | When a defeated aggressor Engineer, IT Professional | Has not, will not nor will ever Proud American Forever | Adhere to terms of its surrender