Quoting Bart Oldeman <[EMAIL PROTECTED]>:
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
