From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Samek Subject: Re: Who knows what was changed in 1.1.3.3 or 1.1.3.4 about file locking? Date: 08 Nov 2002 08:09:37 +0100 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <1036739376.3138.14.camel@localhost.localdomain> References: Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: List-Id: Content-Type: text/plain; charset="iso-8859-1" To: Bart Oldeman Cc: Linux-MSDOS Mailing list On P=E1, 2002-11-08 at 00:00, Bart Oldeman wrote: > On 7 Nov 2002, Michal Samek wrote: >=20 > > OK. > > Here is the full log. >=20 > 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 db= f it > was trying to manipulate. >=20 > Attached is a quick&dirty "proof of concept" 64-bit file offset patch= =2E Of > course it will need to be changed to be compatible with older libc's = and > kernels. >=20 > 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 lockin= g problem with our clipper apps. Thanks --=20 Michal Samek - 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