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/g
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 reasons:
1) "check" is only true when the internal functions
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,
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 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 i
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, the sid or the name,
but never the other fields.
I wanted to av
Christopher Faylor wrote:
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 fa
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
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
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 manip
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 Chang
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
On Mon, Jan 20, 2003 at 09:51:31PM -0500, Pierre A. Humblet wrote:
>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).
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 i
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_print
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
chan
At 06:49 PM 1/18/2003 -0500, Christopher Faylor wrote:
>
>I think I have it fixed in my current sources. Don't bother.
>
OK, thanks. A thought came to my mind. The current code (as of
last night) was relying on pw_idx starting at 0, and then playing
tricks with subtracting and adding 1. But the sa
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 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 n
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
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 the
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 m
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 correct
> 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
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.
C
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 to
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
27 matches
Mail list logo
