I have noticed the same problem. With fcntl locks, the lock isn't
associated with a file descriptor, it's associated with the file, so if
someone opens the file, checks the lock and closes the file in the same
process, the lock is released.
Since it's a required lock, perhaps Solaris
, Jason Pollock wrote:
Jason Pollock wrote:
I have noticed the same problem. With fcntl locks, the lock isn't
associated with a file descriptor, it's associated with the file, so
if someone opens the file, checks the lock and closes the file in
the same process, the lock is released.
Since it's
Christian Theil Have wrote:
Hi
I think it looks good :-) I was working on some similar code based on
a dict, which I was still testing out, but your patch is cleaner.
I look forward to trying it out, but I wont have the opportunity to
test it until Monday though.
About changing close and
Christian Theil Have wrote:
I've been testing the patch and it seems to work out allright :-)
A few notes;
#include sys/stat.h
must be outside #ifdef SunOS - other systems needs it too
in unlock_and_fclose(FILE *fp)
fclose is only called in #else, I suppose that should have been like for
P. A. Bagyenda wrote:
Thanks for the review.
If you would, kindly share a non-destructive patch for further
discussion.
Here are the changes that I applied based on the comments.
Index: mms_util.c
===
RCS file:
P. A. Bagyenda wrote:
Jason,
Thanks. It would be nice to see a full patch against latest CVS for
this.
As I've said, my version of Mbuni is drastically different from CVS. :)
I'll see what I can do.
On Sep 19, 2008, at 02:16, Jason Pollock wrote:
P. A. Bagyenda wrote:
Thanks
