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 <[EMAIL PROTECTED]> - 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
