Lock Error on X# 27

[Horst]

Hi
I have a problem with the new X#27 .
This is the Error MSG

Beschreibung : Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess einen Teil der Datei gesperrt hat.

Subsystem : DBFCDX
Generischer Code : EG_LOCK_ERROR Lock-Fehler
Untercode : 1130 Unknown SubCode
Betriebssystemcode : 33 Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess einen Teil der Datei gesperrt hat
FuncSym : INIT
Schwere : ES_ERROR
Kann Default : False
Kann erneut versuchen : False
Kann ersetzen : False
Datei : C:XIDEProjectsSwissbaseBinDebuglogindbfUser.dbf
Aufrufreihenfolge :
bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
bei System.IO.__Error.WinIOError()
bei System.IO.FileStream.Lock(Int64 position, Int64 length)
bei XSharp.IO.XsFileStream.Lock(Int64 position, Int64 length)
bei XSharp.IO.XsFileStream.Lock(Int64 position, Int64 length)
bei XSharp.FileStreamExensions.SafeLock(FileStream oStream, Int64 offset, Int64 length)
bei XSharp.RDD.FPTMemo._tryLock(Int64 nOffset, Int32 nLong, Int32 nTries)
bei XSharp.RDD.FPTMemo.LockHeader(Boolean refreshHeaders)
bei XSharp.RDD.FPTMemo.OpenMemFile(DbOpenInfo info)
bei XSharp.RDD.DBF.OpenMemFile(DbOpenInfo info)
bei XSharp.RDD.DBF.Open(DbOpenInfo info)
bei XSharp.RDD.DBFCDX.Open(DbOpenInfo info)
bei XSharp.CoreDb.<>c__DisplayClass114_0.b__0()
bei XSharp.CoreDb.Do[T](Func`1 action)
bei XSharp.CoreDb.UseArea(Boolean lNew, Type rddType, String cName, String cAlias, Boolean lShare, Boolean lReadOnly)
bei XSharp.CoreDb.<>c__DisplayClass112_0.b__0()
bei XSharp.CoreDb.Do[T](Func`1 action)
bei XSharp.CoreDb.UseArea(Boolean lNew, _RddList rddList, String cName, String cAlias, Boolean lShare, Boolean lReadOnly)
bei XSharp.RT.Functions.VoDbUseArea(Boolean lNewArea, _RddList rddlist, String cDataFile, String cAlias, Boolean lShared, Boolean lReadOnly)
bei VO.DbServer..ctor(__Usual[] Xs$Args)
bei _CryptServer..ctor(__Usual[] Xs$Args) in C:XIDEProjectsSwissbaseApplications_Swissbase-FunctionenDatenbank.prg:Zeile 365.
bei CgiContext..ctor(String cRoot, HttpListenerRequest oRequest, String cPostGetStream) in C:XIDEProjectsSwissbaseApplications_Swissbase-FunctionenKlassenCgiContext.prg:Zeile 210.
bei ElektroKontrollContext..ctor(String cRoot, HttpListenerRequest oRequest, String cPostGetStream) in C:XIDEProjectsSwissbaseApplications_KontrollKlasse.prg:Zeile 16.
bei ElektroKontrollDruckContext..ctor(String cRoot, HttpListenerRequest oRequest, String cPostGetStream) in C:XIDEProjectsSwissbaseApplicationsElektro Kontroll DruckMenue__Start.prg:Zeile 52.
bei Elektro Kontroll DruckMenue.Functions.StartElektroKontrollDruck(HttpListenerRequest oRequest, String cPostGetStream) in C:XIDEProjectsSwissbaseApplicationsElektro Kontroll DruckMenue__Start.prg:Zeile 28.
bei Service.HttpServer.Response(HttpListenerContext ocontext) in C:XIDEProjectsSwissbaseApplicationsWebServerPrgHttpServer.prg:Zeile 305.
bei Service.HttpServer.Processor(Int32 number, BlockingCollection`1 messages) in C:XIDEProjectsSwissbaseApplicationsWebServerPrgHttpServer.prg:Zeile 94.
bei Service.HttpServer.<>c__DisplayClass11_0.b__0() in C:XIDEProjectsSwissbaseApplicationsWebServerPrgHttpServer.prg:Zeile 80.
bei System.Threading.ThreadHelper.ThreadStart_Context(Object state)
bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Threading.ThreadHelper.ThreadStart()

I am was checking my prg and the whole project. I just open User.dbf , reading and then i close the dbf.
DbServer {WorkDir ()+ SELF:cPathDbfSys + "User.dbf" , TRUE,FALSE,"DBFCDX"}
But ! I call this thread at the same time many times, depending how many documents has to be created.

I was goining back to X#2.6 and i had no problems, installing 2.7 again and the problems/errors comes back.
So i am quit sure it has something to do with the new version. Any hint ?

Horst

[Chris]

Hi Horst,

Sorry about the problem, looks like it has to do with opening and using the .fpt file. Can you please show us the exact relevant code, from opening the dbf till closing it? You can send it privately, if you do not want to post it here.

Also how many threads do you open? And does the problem happen every single time you run the app, or does it happen only randomly?

[Horst]

Hi Chris
Its not allways. Mostly when i start 3 and up threads.
In one case i call the dll 3 times (making 3 documents) and the last one crashed on the User.dbf
User.dbf is the first dbf i am opening.

i tryed then the same case again and told him to produce 12 documents and it crashed on the 4th document (crashed on a dbf deeper in the prozess) and 5th (User.dbf again ) document, before and after works normal.

i can zip the project and send it to you. How to send it private ?

Horst

[Chris]

Hi Horst,

Just please send it to my email, chris at xsharp (dot)eu

[Meinhard]

Hi Horst,

could it be that you've been hit by Microsoft wonderful SMB protocol changes? I had this a couple of times at customer sites. The problem was, most of the time, thatnew SMB version do something calle opportunistic locking. Unfortunately, AFAIK, this can't be switched off any more. What happens if you wait some time before you try to open again (as Windows will unlock the handle after it hasn't been used for a while automatically)?

Regards
Meinhard

[Horst]

Hi Chris and Meinhard
Chris i will send it with a flow chart.

Meinhard, Sorry i dont know SMB protocol, i know it was working on X# 2.6 before i update to 2.7

Horst

[mainhatten]

The problem was, most of the time, thatnew SMB version do something called opportunistic locking.

MS screwed SMB up royally with opportunistic locking (oplocks) after SMB1, that is certain. But SMB1 already had oplocks, which does speed up things a lot if you are the only user having file open on remote machine (Warning:depending on setup a VM on same physical machine might be cosidered "remote") as agressive caching can be and is used. Whenever second person opened any file shared, SMB1 stopped caching totally. That was done for all files - dbf, doc, docx, xlsx and so on and allowed ISAM usage over Samba.
SMB2 "concentrated" more on document file usage as done in Office, where most of the time the whole stream is rewritten - not like dbf, where only record and part of cdx tree is rewritten. DBF were corrupted sooner or later when multiple users wrote into table with shared access rights, even if file handler (vfp) did lock records automatically during write - that was cached as well... brain fart...

Unfortunately, AFAIK, this can't be switched off any more.

Hmm, this is news to me. My latest take on things was that SMB1, which has no problems at all with oplocks and downgrading caching when second user opens file, can be hacked now within minutes and should not be allowed in any network. SMB2 is/was disaster zone for any ISAM file handling usage. SMB3 does allow you to set certain registry keys, which tune down caching which MIGHT eliminate such errors and stay in less hackable SMB3 level, but the danger is in every Windows update, where they might introduce new SMB "features" or screw up registry keys you set on purpose as Seattle thinks they know better. Not good if you think your data is important...

Paranoid me still uses dbf a lot when they are local to the machine. But dbf across network is so suspect that I either allow only exclusive use and free resources afterwards, working by choice in a disconnected frame of mind and have to synch on row level write counts (timestamp in ISAM usage is not atomic due to each machine having its own idea of now on a QueryPerformanceCounter level - getting Internet time is not fine grained enough) or use a C/S data store for data on remote machines.

As Robert had to optimize some data access, it might be connected as 2.7 might use its own caching on top.
So best litmus test here would be to run suspicious code parts only with exclusive dbf access

my 0.02€
thomas

[robert]

Horst,
Did you see this exception in the Front end of the app or in the debugger.
There is a TRY .. CATCH inside XSharp.FileStreamExensions.SafeLock() that should catch the exception and save the exception in the runtime state and should return FALSE to indicate that the lock failed:

Robert

[Chris]

Robert, it's in the front end, I have logged a couple related reports.