[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-msdos
Subject: Re: Where are the problems with file locks in dosemu ?
From: Grzegorz Prokopski <prokopsk () novell ! itn ! pwr ! wroc ! pl>
Date: 2000-07-22 21:13:48
[Download RAW message or body]
jt@npdaxp.fuw.edu.pl wrote:
> >From: Grzegorz Prokopski <prokopsk@novell.itn.pwr.wroc.pl>
>
> >If You mount a share on NFS(nfsd), SMB (samba), NCP (NovellNetware)
> >file locking work only "locally". I mean if there are some dosemus on
> >one machine using /mnt/share and content - they can see their locks.
>
> There is yet another problem: DosEmu and SMB do not see access by
> Mars (Martin Stover's NetWare server). I am still working on it.
You mean - they can't see file locks done by the other ?
I am not sure, but have two thoughts (possibly no one is right):
- samba client (smbfs) doesn't support locking ;(
- samba server uses OWN file locking database, not using native unix
locks, so You can lock the file by win client, and then inside unix
again.
(Remember that Posix locks and BSD-style file locks can't be used
together. If You search linux-kernel archive Alan Cox wrote some time
ago that those two types of locking are not seen by each other -
would MarsNWE use BSDstyle locks? - dosemu is using posix.)
> >NCP: Thanks to Petr Vandrovec I have a path that gives You properly
> >working locks on NCPFS but... there are problems with file size.
> >If the file is opened by more than one station, the file size
> >reported by Novell (3.11 - at least tested, but said to be the same
> >for every other version) is all the time the size when FIRST station
> >opened the file - no matter what was written to the file.
>
> What conditions are needed to see it? Native Novell NetWare server,
> or Mars on Linux? DOS client for NetWare or NCPFS on Linux?
Petr confirmed that it is normal (and only) behaviour of all Netware
servers. You can read/write to file, but asking system to get file size
is a nonsense. It (Netware and then Linux) will give You size of file,
when it was first opened (no matter if it was done by Linux or Dos
station).
Here goes what I wrote to Petr and Eric:
/////
I got some book of Int21H in front of me.
Looking at 3dh function (file open) I see, that there are
two modes of file opening. Mode bits are:
7 - doesn't really matter
4..6: 000 - every client can open the file simultanously, but
only in this mode.
001 - exclusive access only
010 - exclusive writing... others can only read, but not
000 mode
011 - exclusive reading... others can only read, but not
000 mode
100 - others can write and read, but not 000 mode
0..3: 0000 - reading
0001 - writing
0010 - reading and writing
(000 mode <=> other modes)
Mode 000 was first and DOS uses it to open and load .exe file.
But if I open .exe from inside dosemu ncpfs translates file open
always to 100 mode. And that is OK. I just make another copy of
.exe.
\\\\\\
Linux alway opens file in "not 000" mode. "Normal" dos programs use
000 (MS-DOS uses it to load .exe files too, so if you run exe iside
dosemu, you cant run it on dos station - you need a second copy ;( ),
so you even won't open the file under NortonCommander for ex.
But You can write own program in Pascal (as I did) that uses:
FileMode:=66 ? /* 0100 0010 binary or sth like that*/
Then You'll see that content of file can be larger that system reports.
(while not EOF(file_des) do blockread....)
So this behavior is seen on Linux and Dos stations - no difference.
Haven't tested it on MarsNWE. As it is based on Linux their behavior
maight be normal.
> >SMB: I wrote 3 letters to different addresses on smb related lists
>
> SMB is part on which I did not have my hands on. But I will need...
If You get ANY info that could be userful please contact me.
> >PS: If You want a patch for NCPFS file locking write to me
>
> I would like to put on my WWW page all patches or URL-s to them
> - if you know about any, please send me the info.
>
> Jerzy Tarasiuk
So here it goes - please put it on Your web page if You wish.
Please include this and previous e-mail also if You can.
That would make sense and state of these patches clear.
To compile dosemu after applying this patch You need to get ncpfs
sources and "make install-dev", then do
"ln -s /usr/local/include/ncp /usr/include/ncp"
I attached the patches to email - they are very small (about 2kB).
Best reagards
Grzegorz Prokopski
PS: If anyone have access to NW server - can do a following test.
Mount a share from NW server.
Open the file under dos (but not 000 mode) and write sth to it.
Then look at its size under linux. Has it changed ? Probably no.
using "cat" or mc viewer won't get you the contents beyond old size.
Peter suggested using dd which would make things much cleaner
- is this cat/mc problem or ncpfs/VFS(kernel) problem ?
I havent opportunity to test it.
I used 2.2.5 for it. What about newer kernel ?
Please write to me If You sucseed.
["mfs.h.patch" (application/octet-stream)]
--- ./dosemu-1.0.0/src/dosext/mfs/mfs.h Sun Mar 5 13:57:37 2000
+++ ./dosemu-1.0.0-greg/src/dosext/mfs/mfs.h Sat Jun 24 11:03:27 2000
@@ -10,6 +10,9 @@
emulator.
Andrew.Tridgell@anu.edu.au 30th March 1993
*/
+/* For file locking on nfs mounted shares - comment out if causes problems*/
+
+#include <ncp/kernel/ncp_fs.h>
#ifdef DOSEMU
/* definitions to make mach emu code compatible with dosemu */
["mfs.c.patch" (application/octet-stream)]
--- ./dosemu-1.0.0/src/dosext/mfs/mfs.c Sun Mar 5 13:57:37 2000
+++ ./dosemu-1.0.0-greg/src/dosext/mfs/mfs.c Sat Jul 22 22:28:37 2000
@@ -3761,6 +3761,42 @@
ret = fcntl (fd,F_SETLK,&larg);
Debug0((dbg_fd, "lock fd=%x rc=%x type=%x whence=%x start=%lx, len=%lx\n",
fd, ret, larg.l_type, larg.l_whence, larg.l_start,larg.l_len));
+ /* This piece of code pretends to make file locking working
+ on NetWare (Novell) shares, where the file is accessed by
+ other clients also (on ONE linux box locking works locally without it)
+ Thanks to Petr Vandrovec for explainations.
+ Warning: You need to have 'Proprietary file locking' in ncpfs
+ enabled. On NetWare (Novell) share program MUST lock and
+ unlock exactly the same piece of file or else it will
+ cause a memory leak in the kernel.
+ If I could help You please write:
+ Grzegorz Prokopski (prokopsk@novell.itn.pwr.wroc.pl)
+ */
+#if 1
+ if (ret !=-1) { // linux (un)locking was sucessfull
+ struct ncp_lock_ioctl ncplock;
+ int err;
+ ncplock.cmd = (larg.l_type==F_UNLCK) ? NCP_LOCK_CLEAR : NCP_LOCK_EX;
+ ncplock.origin = 0;
+ ncplock.offset = pt->offset;
+ ncplock.length = pt->size;
+ ncplock.timeout = 0;
+ err = ioctl(fd, NCP_IOC_LOCKUNLOCK, &ncplock);
+ Debug0((dbg_fd, "ncplock fd=%x result=%x cmd=%x origin=%x offset=%x size=%x timeout=%x\n",
+ fd, err, ncplock.cmd, ncplock.origin, ncplock.offset, ncplock.length, ncplock.timeout));
+ if (err < 0) {
+ if (errno == EAGAIN) {
+ if (larg.l_type!=F_UNLCK) {
+ larg.l_type=F_UNLCK;
+ fcntl (fd,F_SETLK,&larg);
+ ret = -1;
+ };
+ } else if (errno == EINVAL) {
+ Debug0((dbg_fd, "NCPLock failed - no ncplocking in kernel or file not on ncpfs\n"));
+ } else Debug0((dbg_fd, "NCPError: %s\n", strerror(errno)));
+ };
+ };
+#endif
return ret != -1 ? TRUE : FALSE;
}
break;
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic