http://bugzilla.novell.com/show_bug.cgi?id=1018908 http://bugzilla.novell.com/show_bug.cgi?id=1018908#c5 --- Comment #5 from Richard Palethorpe --- OK, thanks for the explanation. So the problem now is that in the POSIX manual page for fork() it says all file locks should not be inherited, but then goes on to say that the states of objects such as mutexes may be copied to the new process so you should call exec (as you say). I am wondering what locks it could be referring to here? Perhaps it means "if the parent has locked a file through the kernel, then the child should _not_ be able to access the file" or it could mean that during the fork the thread locks are removed from the child's memory so that the child _can_ access the file. In other words, depending on how you interpret the word 'inherit' and the phrase 'file locks' it could mean one of two complete opposites. Incidentally the file lock succeeds if we call ftrylockfile in the child's main thread so presumably the thread ID is the same between child and parent. The test creates another thread in the child before trying to lock the file. Previously the test passed when doing this. Clearly the original test author thought that 'file locks' referred to the POSIX file locks implemented by libc for thread synchronisation. -- You are receiving this mail because: You are on the CC list for the bug.