Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Michal Samek]

Hi,
I am using 1.1.3.4 but not sure if it started with 1.1.3.3 patch:

when I start the .exe app within dosemu session, it's impossible to
start another instance within win session (data/app on samba, lredired
smbmounted on linux), .exe file is locked (open READ DENY ALL if I can
remember mode). 

I'm sure that before 1.1.3.* it was possible.

But I think it can be someone's try to fix the file locking problem, am
I right? If so, something really changed, but not at all good. Maybe
someone could try to correct it?

-- 
Michal Samek <webmaster@tony.cz>

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Bart Oldeman]

[second try, I'll cc the mailing list for clarification; problem was:
DOSEMU executes exe file, uses ??? mode. the exe file is on a Linux samba
server, mounted via smbfs.
As long as the exe file is opened, a Win9x samba client refuses to open
the file.
]

On 30 Oct 2002, Michal Samek wrote:

> I can understand that -D+Dd logs disk operations but I can't locate
> where dosemu writes it's log - there is no terminal output and /var/log
> files are same sized as before running dosemu. Where I can find logs?

If you use "dosemu" then the log is in boot.log in ~/dosemu, otherwise
you have to use

dos -D+Dd -o log

and find the log output in the file named log in the current directory.

> It looks like when dosemu should really open the file in READ-SHARE mode
> (don't remember exactly dos modes) it opens the file in READ-DENY mode.
> And still when it opens the file in READ-DENY mode (locking problem) it
> results in READ-SHARE mode which is the same bad as before. But now it's
> sure that it IS POSSIBLE to lock the file via dosemu. Unfortunatelly it
> happens when it shouldn't and otherwise if you understand me :)

If DOS opens a file in COMPATIBILITY or DENY_NONE mode then DOSEMU will
not apply any lock.

If DOS opens a file in DENY_WRITE mode (which you claim it does
basically, but then, I don't have a log yet) then DOSEMU will apply an
F_RDLCK lock from 2^31-1 to 2^31.

If DOS opens a file in DENY_READ mode then DOSEMU will apply a F_WRLCK
(exclusive) lock from 2^31-1 to 2^31, except when the file is opened R/O.

If DOS opens a file in DENY_ALL mode then DOSEMU will apply an F_RDLCK
(shared) lock if the file is opened R/O and an F_WRLCK (exclusive) lock
from 2^31-1 to 2^31 if the file is opened R/W or write-only.

A UNIX F_RDLCK (shared) _advisory_ lock (which is what DOSEMU applies in
the case you describe) basically tells other processes that they cannot
lock that part of the file for writing, so this very roughly corresponds
to DOS DENY_WRITE. (but not completely; see the table in mfs.c for
differences in behaviour (modulo bugs)).

Now I'm not sure where the bug is (DOSEMU, smbfs, Samba, or Win9x).

Bart

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Bart Oldeman]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 472 bytes --]

On 7 Nov 2002, Michal Samek wrote:

> OK.
> Here is the full log.

Thanks, it turns out that your .exe locked a dbf file (using region
locking) with strange offsets. So it might not have been the problem with
there being a shared lock on the .exe but rather a conflict in the dbf it
was trying to manipulate.

Attached is a quick&dirty "proof of concept" 64-bit file offset patch. Of
course it will need to be changed to be compatible with older libc's and
kernels.

Bart

[-- Attachment #2: Type: TEXT/PLAIN, Size: 3655 bytes --]

--- dosemu-1.1.3.7/src/dosext/mfs/mfs.c	Fri Oct  4 11:16:06 2002
+++ dosemu-1.1.3.8/src/dosext/mfs/mfs.c	Thu Nov  7 17:49:04 2002
@@ -153,6 +153,7 @@
 
 /* Modified by O.V.Zhirov at July 1998    */
 
+#define _FILE_OFFSET_BITS 64
 
 #if defined(__linux__)
 #define DOSEMU 1		/* this is a port to dosemu */
@@ -2937,7 +2938,7 @@
       fd = sft_fd(sft);
       Debug0((dbg_fd, "Read file fd=%x, dta=%p, cnt=%d\n",
 	      fd, (void *) dta, cnt));
-      Debug0((dbg_fd, "Read file pos = %ld\n",
+      Debug0((dbg_fd, "Read file pos = %lu\n",
 	      sft_position(sft)));
       Debug0((dbg_fd, "Handle cnt %d\n",
 	      sft_handle_cnt(sft)));
@@ -2971,7 +2972,7 @@
       sft_abs_cluster(sft) = 0x174a;	/* XXX a test */
 /*      Debug0((dbg_fd, "File data %02x %02x %02x\n",
 	      dta[0], dta[1], dta[2])); */
-      Debug0((dbg_fd, "Read file pos after = %ld\n",
+      Debug0((dbg_fd, "Read file pos after = %lu\n",
 	      sft_position(sft)));
       return (return_val);
     }
@@ -3004,7 +3005,7 @@
     }
     Debug0((dbg_fd, "Handle cnt %d\n",
 	    sft_handle_cnt(sft)));
-    Debug0((dbg_fd, "sft_size = %x, sft_pos = %x, dta = %p, cnt = %x\n", (int)sft_size(sft), (int)sft_position(sft), (void *) dta, (int)cnt));
+    Debug0((dbg_fd, "sft_size = %lx, sft_pos = %lx, dta = %p, cnt = %x\n", sft_size(sft), sft_position(sft), (void *) dta, (int)cnt));
     if (us_debug_level > Debug_Level_0) {
       ret = dos_write(fd, dta, cnt);
       if ((ret + s_pos) > sft_size(sft)) {
@@ -3792,15 +3793,17 @@
     return TRUE;
   case SEEK_FROM_EOF:		/* 0x21 */
     {
-      int offset = (state->ecx << 16) + WORD(state->edx);
+      off_t offset = (unsigned long))((state->ecx << 16) + WORD(state->edx) + sft_position(sft));
+      if (offset < 0) {
+	SETWORD(&(state->eax), SEEK_ERROR);
+	return (FALSE);
+      }
       fd = sft_fd(sft);
-      Debug0((dbg_fd, "Seek From EOF fd=%x ofs=%d\n",
-	      fd, offset));
-      if (offset > 0)
-	offset = -offset;
-      offset = lseek(fd, offset, SEEK_END);
-      Debug0((dbg_fd, "Seek returns fs=%d ofs=%d\n",
-	      fd, offset));
+      Debug0((dbg_fd, "Seek From EOF fd=%x ofs=%lld\n",
+	      fd, (long long)offset));
+      offset = lseek(fd, offset, SEEK_SET);
+      Debug0((dbg_fd, "Seek returns fs=%d ofs=%lld\n",
+	      fd, (long long)offset));
       if (offset != -1) {
 	sft_position(sft) = offset;
 	SETWORD(&(state->edx), offset >> 16);
@@ -3825,11 +3828,12 @@
 		int fd = sft_fd(sft);
 		int ret;
 		struct LOCKREC{
-			long offset,size;
+			unsigned long offset,size;
 		} *pt = (struct LOCKREC*) Addr (state,ds,edx);
 		struct flock larg;
+#if 0                
 		unsigned long mask = 0xC0000000;
-
+#endif
 
 #if 1   /* The kernel can't place F_WRLCK on files opened read-only and
          * FoxPro fails. IMHO the right solution is:         --Maxim Ruchko */
@@ -3848,6 +3852,7 @@
 		larg.l_len = pt->size;
 		larg.l_pid = 0;
 
+#if 0
 		/*
 			This is a superdooper patch extract from the Samba project
 			We have no idea why this is there but it seem to work
@@ -3871,9 +3876,11 @@
 		if ((larg.l_start & mask) != 0)
 			larg.l_start = (larg.l_start & ~mask) | ((larg.l_start & mask) >> 2);
 
+#endif
 		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));
+		Debug0((dbg_fd, "lock fd=%x rc=%x type=%x whence=%x start=%llx, len=%llx\n",
+			fd, ret, larg.l_type, larg.l_whence, (long long)larg.l_start,
+                        (long long)larg.l_len));
 		if (ret == -1) SETWORD(&(state->eax), ACCESS_DENIED);
 		return ret != -1 ? TRUE : FALSE;
 	}

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Michal Samek]

On Pá, 2002-11-08 at 00:00, Bart Oldeman wrote:
> On 7 Nov 2002, Michal Samek wrote:
> 
> > OK.
> > Here is the full log.
> 
> Thanks, it turns out that your .exe locked a dbf file (using region
> locking) with strange offsets. So it might not have been the problem with
> there being a shared lock on the .exe but rather a conflict in the dbf it
> was trying to manipulate.
> 
> Attached is a quick&dirty "proof of concept" 64-bit file offset patch. Of
> course it will need to be changed to be compatible with older libc's and
> kernels.
> 
> Bart

Yes, it tries to lock some file just on start. It's the way it detects
if there are another active sessions. But I think it's another problem
because I still can't even start the another session when the
application exe file is in use inside the dosemu session. Win tells me
that file is unaccessible or something similar (we have czech localized
wins) and I guess that the dosemu session opens the exe file as
READ-DENY-ALL. I will check it once again to be sure.

I'm going to try the patch, maybe it will solve the record-level locking
problem with our clipper apps.

Thanks
-- 
Michal Samek <webmaster@tony.cz>

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Michal Samek]

On Pá, 2002-11-08 at 08:09, Michal Samek wrote:
> On Pá, 2002-11-08 at 00:00, Bart Oldeman wrote:
> > On 7 Nov 2002, Michal Samek wrote:

> Yes, it tries to lock some file just on start. It's the way it detects
> if there are another active sessions. But I think it's another problem
> because I still can't even start the another session when the
> application exe file is in use inside the dosemu session. Win tells me
> that file is unaccessible or something similar (we have czech localized
> wins) and I guess that the dosemu session opens the exe file as
> READ-DENY-ALL. I will check it once again to be sure.
> 

I've checked it and it's true; when I start the app inside a dosemu
session, it locks the app .exe file - it's impossible to access the file
from any other win sessions. The app is invoked from a standart .bat
file so I hope that my drdos tries to open it as READ-ONLY, DENY-NONE
but some underlying layer in fact opens the .exe file as DENY-ALL. And I
think it should be some new/chgd code in mfs.c because this is a new
behaviour for me after aplying 1.1.3.3 or 1.1.3.4 patches. Maybe it's
somewhat specific to my setup, eg. samba/smbfs mount/lredir and can
depend on versions/configuration of kernel/samba I use, I don't know.

-- 
Michal Samek <webmaster@tony.cz>

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Sergey Suleymanov]

>>>>> Bart Oldeman writes:

 Bart> Attached is a quick&dirty "proof of concept" 64-bit file offset
 Bart> patch. Of course it will need to be changed to be compatible
 Bart> with older libc's and kernels.

        I hope this will be compile-time option. I'm using mars_nwe
        for file sharing and it use regular offsets for locking.

-- 
  Sergey Suleymanov

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Bart Oldeman]

On 10 Nov 2002, Sergey Suleymanov wrote:

> >>>>> Bart Oldeman writes:
>
>  Bart> Attached is a quick&dirty "proof of concept" 64-bit file offset
>  Bart> patch. Of course it will need to be changed to be compatible
>  Bart> with older libc's and kernels.
>
>         I hope this will be compile-time option. I'm using mars_nwe
>         for file sharing and it use regular offsets for locking.

but 64-bit locks work just fine for regular offsets.
The advantage is that this strange bit-fiddling for irregular offsets
isn't necessary anymore.

Or did I miss something?

Bart

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Sergey Suleymanov]

>>>>> Bart Oldeman writes:

 Bart> On 10 Nov 2002, Sergey Suleymanov wrote:
 > Bart Oldeman writes:
 >>
 Bart> Attached is a quick&dirty "proof of concept" 64-bit file offset
 Bart> patch. Of course it will need to be changed to be compatible
 Bart> with older libc's and kernels.
 >>  I hope this will be compile-time option. I'm using mars_nwe for
 >> file sharing and it use regular offsets for locking.

 Bart> but 64-bit locks work just fine for regular offsets.  The
 Bart> advantage is that this strange bit-fiddling for irregular
 Bart> offsets isn't necessary anymore.

 Bart> Or did I miss something?

        Hmm. No, you didn't. I'm sorry. Locking works fine.

        I'm just test the patched dosemu and another dos through a
        mars/netx and it seem works.

-- 
  Sergey Suleymanov

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Przemyslaw Czerpak]

On Sun, 10 Nov 2002, Sergey Suleymanov wrote:
>  Bart> Attached is a quick&dirty "proof of concept" 64-bit file offset
>  Bart> patch. Of course it will need to be changed to be compatible
>  Bart> with older libc's and kernels.
>         I hope this will be compile-time option. I'm using mars_nwe
>         for file sharing and it use regular offsets for locking.

mars clears the highest bit in locks offset - see nwshare.c file.
I've added 64bit locking to mars but I haven't public the patch
so far because I haven't time to change the method of file share mode
emulation. I want to make it samba compatible. If anyone on the list
is similar with samba code and can help it will be nice.
Last week Bart's sent patch for full 32bit locks in DOSEMU so I think it's
time to realize my changes to mars to make it compatible.
I will do that to the end of next week.

best regards,
Przemek

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Michal Samek]

On Pá, 2002-11-08 at 00:00, Bart Oldeman wrote:

> Attached is a quick&dirty "proof of concept" 64-bit file offset patch. Of
> course it will need to be changed to be compatible with older libc's and
> kernels.
> 
> Bart


There is a small typo in your patch; mfs.c after patching, line 3796.
I hope there should be:

(unsigned long)( ...

instead of 

(unsigned long))(...

It compiles now; I'm going to check the locking behaviour.

-- 
Michal Samek <webmaster@tony.cz>

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking?

[Michal Samek]

On Pá, 2002-11-08 at 00:00, Bart Oldeman wrote:

> Attached is a quick&dirty "proof of concept" 64-bit file offset patch. Of
> course it will need to be changed to be compatible with older libc's and
> kernels.
> 
> Bart

So I've started a patched dosemu but there is something very strange,
when I open a .dbf file with the dbu (clipper dbf browser utility) in
shared mode, I can see ONLY THE FIRST RECORD of every .dbf table I have.
Do you have some idea what it can be? I didn't test the locking
behaviour, should I? I think it's broken so much that it has no sense. 

Due to my lack of the C and the low-level programming knowledge I can't
say more about it. If there is someone interested I can send him the log
file with my session.

Anyway thanks for your help
-- 
Michal Samek <webmaster@tony.cz>

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html