After consolidating all of the lock code into a refresh method,
I realized that there are some pretty big races in the group/passwd
code. You can't just protect the reading of the buffers against
multiple access, you have to protect all operations which manipulate
the passwd/group buffers since
Christopher Faylor wrote:
Also, implying that there is a one-to-one correspondence between my
ChangeLog entries and the ones for your patches is a little simplistic.
It would be, but I never compared them. I only remarked that this
became one of your largest recent projects (in terms of
Christopher Faylor wrote:
After consolidating all of the lock code into a refresh method,
I realized that there are some pretty big races in the group/passwd
code. You can't just protect the reading of the buffers against
multiple access, you have to protect all operations which manipulate
On Tue, Jan 21, 2003 at 10:39:00AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You had no comments on my last observation, MS doesn't raise an event
on mv and rm.
I'll tell you why I had no comment on this if you tell me why you had
no comment on the fact that I'd indicated I was
On Tue, Jan 21, 2003 at 10:53:29AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
This has been there forever, I would not delay the release of 1.3.19
Did I say I was delaying anything?
By the way, I wrote the internal_get{pw,gr} routines having in mind
that they could be extended to
On Tue, Jan 21, 2003 at 10:39:00AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You had no comments on my last observation, MS doesn't raise
an event
on mv and rm.
I'll tell you why I had no comment on this if you tell me why you had
no comment on the fact that I'd indicated I
On Tue, Jan 21, 2003 at 11:47:35AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You'd need a per-thread buffer to accomplish that. I assume that
is what you had in mind.
If you look at them, most internal_get{pw,gr} calls from outside
of passwd.cc and grp.cc only want the
On Tue, Jan 21, 2003 at 11:47:35AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You'd need a per-thread buffer to accomplish that. I assume that is
what you had in mind.
If you look at them, most internal_get{pw,gr} calls from outside of
passwd.cc and grp.cc only want the {u,g}id,
On Tue, Jan 21, 2003 at 06:42:25PM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
Btw, Pierre, can you explain the rationale behind the check parameter
that some of the internal_* functions take? Why would you not want to
check for an up-to-date /etc/passwd or /etc/group?
Two
Mostly good news recently:
1) Chris' 51 line ChangeLog on 01-19 is his personal best since Sept 2000.
When combined with the 31 line ChangeLog on 01-16, they exceed by
far his record for the millennium (67 lines in Sept 2000).
This is in a thread that has Hmm. I have a slightly less
intrusive
Ok. I took another stab at this, cleaning up some more stuff and moving
(almost) everything into the pwdgrp class. Hardly anything is marked
NO_COPY now.
I moved etc out of uinfo since, as I mentioned, I plan on using it for
more than just passwd/group stuff someday. I renamed sawchange to
On Sun, Jan 19, 2003 at 09:40:01PM -0500, Christopher Faylor wrote:
For the Novell case, I explicitly check the creation time of the file
every time. It may be slower but at least it makes cygwin behavior consistent
regardless of whether the FS.
XXX
I also a debug_printf
At 12:03 AM 1/18/2003 -0500, Pierre A. Humblet wrote:
Chris,
An ugly tought came to my mind while doing the dishes:
there is a race condition left.
Chris, I am going to address this in about an hour,
assuming you are not working on it. Otherwise please
let me know.
Pierre
On Sat, Jan 18, 2003 at 05:37:00PM -0500, Pierre A. Humblet wrote:
At 12:03 AM 1/18/2003 -0500, Pierre A. Humblet wrote:
Chris,
An ugly tought came to my mind while doing the dishes:
there is a race condition left.
Chris, I am going to address this in about an hour,
assuming you are not working
OK, forget what I just wrote, it won't work because the state is
reset to initializing. But the idea of calling init just once
without +/- 1 has potential. Perhaps by adding a 4th state value:
(uninitialized, initializing, reinitializing, loaded).
Pierre
On Fri, Jan 17, 2003 at 12:29:05AM -0500, Christopher Faylor wrote:
Maybe not so less intrusive after all. I broke out the etc handling
stuff into a separate class and moved even more functionality into
pwdgrp than you did. I hope Corinna approves.
As long as it works it's ok with me.
On Thu, Jan 16, 2003 at 02:07:18PM -0500, Christopher Faylor wrote:
On Thu, Jan 16, 2003 at 01:57:21AM -0500, Pierre A. Humblet wrote:
Here is the code as it stands. It compiles runs, and passes
fork tests correctly. Feel free to takeover or at least
have a look. I will continue testing
On Fri, Jan 17, 2003 at 10:06:02AM -0500, Pierre A. Humblet wrote:
On Thu, Jan 16, 2003 at 02:07:18PM -0500, Christopher Faylor wrote:
On Thu, Jan 16, 2003 at 01:57:21AM -0500, Pierre A. Humblet wrote:
Here is the code as it stands. It compiles runs, and passes
fork tests correctly. Feel free
Hello Chris,
I like your code, just made a few changes. The explanations below
are detailed and longer that the changes!
In load(), CloseFile wasn't called on read error, and it was called
before GetFileTime.
It seems that declaring passwd_buf, group_buf etc NO_COPY means that
there will be a
Chris,
An ugly tought came to my mind while doing the dishes:
there is a race condition left.
FindFirstChangeNotification must be called from init, otherwise
in the normal case it will be called after the load, leaving
a window where the file can be updated without being noticed.
Similarly in
On Thu, Jan 16, 2003 at 01:57:21AM -0500, Pierre A. Humblet wrote:
Chris,
Here is the code as it stands. It compiles runs, and passes
fork tests correctly. Feel free to takeover or at least
have a look. I will continue testing tomorrow evening.
I include only the 5 files that are related to
On Thu, Jan 16, 2003 at 02:07:18PM -0500, Christopher Faylor wrote:
On Thu, Jan 16, 2003 at 01:57:21AM -0500, Pierre A. Humblet wrote:
Here is the code as it stands. It compiles runs, and passes
fork tests correctly. Feel free to takeover or at least
have a look. I will continue testing tomorrow
22 matches
Mail list logo
