On Sat, Oct 27, 2001 at 09:59:15PM -0400, Roland McGrath wrote:
> At a quick glance, the code for both (hurdselect.c) looks the same to me,
> but I don't have time right now to examine it too thoroughly. If the
> problem with poll does not happen with select, then hurdselect.c is almost
> certain
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > But that's not so bad. It doesn't mean checking every single entry
> > in both directories; it means checking only those elements which are
> > duplicated names.
>
> Sure; I was referring to the
On Sat, Oct 27, 2001 at 10:12:12PM -0400, Roland McGrath wrote:
> > Similar on line 93 already. d[1] is not initalized correctly.
>
> Well, there's nothing but simple C code before that.
> You can step through from the beginning of the function and see it all.
>
> Be careful not to let gdb confu
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> But that's not so bad. It doesn't mean checking every single entry
> in both directories; it means checking only those elements which are
> duplicated names.
Sure; I was referring to the dir_readdir()s needed for a simple
directory lookup...
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > Why is it not sufficient to add up the link counts of the shadowed
> > directories (compensating for the -2 term) and use that?
>
> In the case where we have file entries with the same names in t
> Similar on line 93 already. d[1] is not initalized correctly.
Well, there's nothing but simple C code before that.
You can step through from the beginning of the function and see it all.
Be careful not to let gdb confuse you. Sometimes it reports bogus types
for variable-sized arrays.
On Sat, Oct 27, 2001 at 09:59:15PM -0400, Roland McGrath wrote:
> I see. It might be telling to recode it using select and see if it behaves
> the same.
D'oh! We had it using select before, and rewrote syslogd to use poll().
I might be able to just use an old version of the code.
> Of course,
On Sun, Oct 28, 2001 at 02:58:30AM +0100, Marcus Brinkmann wrote:
> > (gdb) print d[1].type
> > $23 = -1962934272
> >
> > If gdb doesn't play tricks on me, this is certainly bogus.
> > Note that the first descriptor (0) is the unix socket, while
> > the second is the inet socket.
>
> Similar on
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Why is it not sufficient to add up the link counts of the shadowed
> directories (compensating for the -2 term) and use that?
In the case where we have file entries with the same names in the
shadowed directories, some entries get shadowedd and
I see. It might be telling to recode it using select and see if it behaves
the same. Of course, it would be best if you could reproduce the situation
with a simple test program (e.g. have a process that writes on a unix
socket every few seconds, nothing writing on the inet socket, and a simple
p
On Sun, Oct 28, 2001 at 02:50:46AM +0100, Marcus Brinkmann wrote:
> On Sun, Oct 28, 2001 at 02:37:28AM +0100, Marcus Brinkmann wrote:
> > So glibc returns the wrong values in revents for poll. I am now going to
> > look into glibc select code.
> >
>
> Actually, in hurdselect.c, line 394ff:
>
>
On Sun, Oct 28, 2001 at 02:37:28AM +0100, Marcus Brinkmann wrote:
> So glibc returns the wrong values in revents for poll. I am now going to
> look into glibc select code.
>
Actually, in hurdselect.c, line 394ff:
(gdb) print d[0].type
$22 = 9
(gdb) print d[1].type
$23 = -1962934272
If gdb doe
On Sat, Oct 27, 2001 at 09:40:59PM -0400, Roland McGrath wrote:
> That syslogd backtrace just shows that it is waiting in recvfrom,
> as it normally should be. The interesting state is in pflocal.
Actually not, see my follow up information. syslogd listens on
both unix and inet ports, and the r
That syslogd backtrace just shows that it is waiting in recvfrom,
as it normally should be. The interesting state is in pflocal.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Sun, Oct 28, 2001 at 02:06:48AM +0100, Marcus Brinkmann wrote:
> So at least two bugs involved here? It seems so. Below you can see
> the gdb output of syslogd at the time of sudo hanging. I should be able
> to narrow it further than that by debugging syslogd in more detail.
It was instruct
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually i cared about the performance aspect. If there are shadowed
> directories, which contain _many_ entries and the user simply looks up
> that directory in shadowfs, shadowfs would have to first read _all_
> the directory entries of _all_ of the
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Posix is looser than this, as Roland points out, but absent a really
> good reason (and "it's a bother to code" is probably not a really good
> reason) we should provide consistent sane behavior.
Actually i cared about the performance aspect. If
Hi,
I am happy to be able to present some more info on the problems involving
sudo/pflocal/syslogd.
There seem to be a couple of issues. First, it seems that sudo and
pflocal/libpipe seem to work fine in the normal case. What happens
is that sudo sends a diagnostic line to syslogd. syslogd re
Roland McGrath <[EMAIL PROTECTED]> writes:
> Note, however, that this optimization in find will quite totally break the
> filesystem semantics presented by translators set on regular files. That
> is, a translator set on a regular file may well report S_IFDIR and so a
> find ought to treat it as
Roland McGrath <[EMAIL PROTECTED]> writes:
> By my reading of 1003.1-1996, st_nlink should be "the number of directory
> entries that refer to the file". In a case like this, I think it's pretty
> open to interpretation what constitutes a directory entry; there always
> might be extra entries in
Oy! I had no idea find did that, though I suppose it is reasonable.
By my reading of 1003.1-1996, st_nlink should be "the number of directory
entries that refer to the file". In a case like this, I think it's pretty
open to interpretation what constitutes a directory entry; there always
might
Roland McGrath <[EMAIL PROTECTED]> writes:
> I don't think the st_nlink value on a directory matters much to any
> user.
Sorry, i should have been more precise in my first mail.
GNU find for example uses that value. The wrong (too small) st_nlink
value was the cause for find not searching in th
I don't think the st_nlink value on a directory matters much to any user.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
>> I'm sorry I didn't post my changes earlier, but I was trying to get glibc
>> 2.2.4 to work and make patches for that. Here are my changes for glibc;
>> I'll post my changes to the Hurd as soon as possible,
>
> can you repost them in a sane format, like ASCII or uuencoded?
> The Debian macutils
On Sat, Oct 27, 2001 at 09:09:15PM +0200, Peter Bruin wrote:
> Hi,
>
> I'm sorry I didn't post my changes earlier, but I was trying to get glibc
> 2.2.4 to work and make patches for that. Here are my changes for glibc;
> I'll post my changes to the Hurd as soon as possible,
Hi,
can you repost t
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Hello,
question: is it ok if the st_nlink member of struct stat of virtual
directory nodes in Shadowfs is higher then the number of nodes which
are actually in that virtual directory?
It would be much overhead if Shadowfs would have to do a dir_readdir()
on all the underlying directories just to
27 matches
Mail list logo
