On Mon, 20 Jul 2009, Marco Bernardi wrote: Hi, I think I was not clear enough and confused you so I'll try to be more precise because it may be source of some serious problems.
> I am using linux 2.6 and seems it is like you say, close() didn't release > lock. It for sure release the fcntl() locks as all other POSIX systems. Otherwise it's very serious bug in your kernel and I suggest to check why it does not work correctly. It's documented POSIX behavior. I was writing about BSD locks which we use in Linux to emulate DOS deny flags which are not removed by current Linux kernels and also do not interact with POSIX locks we still need for all other synchrinizations so we can safely use them. But the only one place were BSD locks are usable for us is DENY flags emulation and for all other things we still need POSIX locks. > I have done following test: I have modified "filebuf.c" blocking the > hb_findFile() function... so any use command create a new handle and > it should create problems in POSIX locks. Yes, and it does. > I created a short programs in order to check it in Linux the programs give > net-error while I try to open TEMP in Exclusive: if I have well understood, > in BSD (POSIX locks) neterr() should return .f. > > USE TEMP NEW ALIAS TEMP1 SHARED > USE TEMP NEW ALIAS TEMP2 SHARED > CLOSE > USE TEMP NEW EXCLUSIVE > ?NETERR() // equal .t. After above modification the DENY flags works in Linux because we use BSD locks to emulate them. The modification you made breaks only POSIX locks used for all other synchronizations like RLOCK, FLOCK, APPEND, INDEX READ/WRITE, MEMO READ/WRITE plus on non Linux systems also DENY flags because POSIX locks are used to emulate them. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
