Anderson Pereira Ataides wrote:

> I tried to hack mfs.c an saw some comments about locking. My conclusion is
> that this problem will not be solved between windows and Linux, because they
> do not "speak" same language when topic is locking. I saw there is a piece of
> code extracted from samba source an comment was "I don't know why it's
> there... Someone is playing games with lock/unlock".

locking across the network is problematic indeed. Region locking (on
the same host) can be (partly?) solved using large file support but any
locking across the network will probably remain problematic. Even local
file locking cannot completely match DOS behaviour.

But what you can check is in the following scenario:
suppose the Linux box is a samba server and the Windows client issues a
lock. Now can a DOSEMU which runs on that samba server see that lock?

That depends a lot on the options you set in the samba config file.
however using the command lsof you can see if Linux sees the file as being
locked. If there is an "R", "W", "r" or "w" behind the file descriptor
number then it is indeed and DOSEMU should not be able to read or write
the file (at least, see some lock). If that isn't the case then there must
be a bug somewhere.

If "lsof" does not report one of these letters then there is nothing you
can do about it: the kernel won't see it so DOSEMU won't see it.
The same is true for smbfs and NFS.

If you see no r,R,w or W's then this isn't a DOSEMU problem. Please
report to the maintainers of samba, smbfs or nfs instead.

> So I thought: samba team
> probably have problem too. How do they solve this problem? Do they cope with
> locks keeping track of locks themselves instead of locking linux filesystem?

see the comment in mfs.c:

    /* this is a little heuristic and does not completely
       match to DOS behaviour. That would require tracking
       how existing fd's are opened and comparing st_dev
       and st_ino fields */

This is what Samba does.

DOSEMU would need to maintain a list somewhere which consists of st_dev +
st_ino fields + locking properties (these fields uniquely determine the
file). This should be done by some "DOSEMU file lock state server" that
can talk to all the DOSEMU clients on the same machine. Now as you can
guess that would be quite a bit of work and I certainly will not be
doing this any time soon (though I would happily accept patches of
course).

Bart

-
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

Reply via email to