Achim Gratz Stromeko at NexGo.DE writes:
I guess it does: the mapping that gets created from AD is sometimes 1049120
instead of 544. That depends on the settings in nsswitch.conf and whether
an /etc/group file exists at all or contains an entry for Administrators. I
guess that once this
On Mar 11 17:05, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
With the original passwd and group file in place and nsswitch.conf set to
either files or files db the test fails. With just files getfacl
doesn't show the group ACL at all,
How does it look
On Mar 11 17:12, Achim Gratz wrote:
Achim Gratz Stromeko at NexGo.DE writes:
Exactly. But as revealed above, what was really missing is the
Administrators group. Somehow, when files is in effect, that mapping
doesn't seem to exist unless it is explicitly listed in the file. It does
get
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Ok, so, here's the question. Is your primaryGroupID in AD 544? If not,
you will have to explain to me how this happens. I have found no other
way to reproduce this.
My primary group ID in AD is 513 (Domain Users), just as shown by id, I
Achim Gratz Stromeko at nexgo.de writes:
IIRC, the next call is the write that prints no or yes... there may
have been something like stat_helper inbetween only on Cygwin64, but
I'll have to check again tomorrow.
It's a call to stat_worker with the UNC file path and the stat_worker
handle,
On Mar 11 07:44, Achim Gratz wrote:
Achim Gratz Stromeko at nexgo.de writes:
IIRC, the next call is the write that prints no or yes... there may
have been something like stat_helper inbetween only on Cygwin64, but
I'll have to check again tomorrow.
It's a call to stat_worker with the UNC
Corinna Vinschen corinna-cygwin at cygwin.com writes:
st_atim=531DE525.1B5BB150 (release)
st_atim=531DF887.5D9B9F8 (snapshot)
Access time. On Windows it even changes when requesting certain
kinds of metadata :-P
It's been consistent over many days of testing and the only difference
On Mar 11 12:07, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
st_atim=531DE525.1B5BB150 (release)
st_atim=531DF887.5D9B9F8 (snapshot)
Access time. On Windows it even changes when requesting certain
kinds of metadata :-P
It's been consistent over many
Corinna Vinschen corinna-cygwin at cygwin.com writes:
You don't have to move them away. Just set nsswitch.conf.
Did that and using the snapshot DLL from 2014-03-05 on top of a full
snapshot install from 2014-03-10. The ACL is this:
# file: x86
# owner: gratz
# group: Domain Users
user::---
On Mar 11 15:07, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
You don't have to move them away. Just set nsswitch.conf.
Did that and using the snapshot DLL from 2014-03-05 on top of a full
snapshot install from 2014-03-10. The ACL is this:
# file: x86
#
Corinna Vinschen corinna-cygwin at cygwin.com writes:
With the original passwd and group file in place and nsswitch.conf set to
either files or files db the test fails. With just files getfacl
doesn't show the group ACL at all,
How does it look with any non-AD integrated Cygwin?
...
Achim Gratz Stromeko at NexGo.DE writes:
Exactly. But as revealed above, what was really missing is the
Administrators group. Somehow, when files is in effect, that mapping
doesn't seem to exist unless it is explicitly listed in the file. It does
get auto-created when I use _only_ the db.
Corinna Vinschen corinna-cygwin at cygwin.com writes:
The fact that the shells are doing it right seems to indicate that this
isn't a generic problem. I can't debug this, though. Can you see if
you can figure out what's going on under the hood? Does strace show
anything of interest? Can we
On Mar 10 17:19, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
The fact that the shells are doing it right seems to indicate that this
isn't a generic problem. I can't debug this, though. Can you see if
you can figure out what's going on under the hood? Does
Corinna Vinschen writes:
(\??\X:\install\x86, 0x800390D0) st_size=0, st_mode=0x4000,
st_ino=-197262732544
^^
This is the important snippet, but I don't see how this could have been
different before my patches. The mode is S_IFDIR and
On Mar 10 19:28, Achim Gratz wrote:
Corinna Vinschen writes:
(\??\X:\install\x86, 0x800390D0) st_size=0, st_mode=0x4000,
st_ino=-197262732544
^^
This is the important snippet, but I don't see how this could have been
different
Corinna Vinschen writes:
In that case the stat call is very likely unrelated. There must be some
other call involved in perl.
IIRC, the next call is the write that prints no or yes... there may
have been something like stat_helper inbetween only on Cygwin64, but
I'll have to check again
On 3/4/2014 01:07, Corinna Vinschen wrote:
On Mar 3 22:07, Warren Young wrote:
You have to measure it to find out.
I was inclined to go with Andrey's suggestion for simplicity. What's
yours?
Science!
Survey actual lookup times, and make a statistical determination from
that. e.g. +3
Greetings, Warren Young!
On 3/4/2014 01:07, Corinna Vinschen wrote:
On Mar 3 22:07, Warren Young wrote:
You have to measure it to find out.
I was inclined to go with Andrey's suggestion for simplicity. What's
yours?
Science!
Survey actual lookup times,
TCP is not UDP.
Lookup time is
On Mar 5 08:34, Warren Young wrote:
On 3/4/2014 01:07, Corinna Vinschen wrote:
On Mar 3 22:07, Warren Young wrote:
You have to measure it to find out.
I was inclined to go with Andrey's suggestion for simplicity. What's
yours?
Science!
Survey actual lookup times, and make a
On Mar 3 22:07, Warren Young wrote:
On 3/3/2014 18:36, Andrey Repin wrote:
Once TCP session is established, it remains,
until closed or dropped on either end of the wire.
Have you done the packet capture to prove that Windows does in fact
keep the LDAP connection to the AD server up
On Mar 4 00:44, Andrey Repin wrote:
Greetings, Corinna Vinschen!
I'd need to test it in domain environment,
And with sane number of groups (less than 20), the results are barely
different between different caching strategies (less than 1%, which could
easily be explained by measurement
On Mar 2 14:20, Frank Fesevur wrote:
2014-02-28 22:08 GMT+01:00 Corinna Vinschen:
That's not really a problem but a case of it is as it is. To get the
user and group info, Cygwin has to contact the DC and/or GC and then
runs into a timeout. Right now, the LDAP timeout is set to 3
On Mar 1 02:08, Andrey Repin wrote:
Greetings, Corinna Vinschen!
I've just uploaded a new snapshot to http://cygwin.com/snapshots/
I've sent a reply with testing details, but it may have been caught by SPAM
deflection for excess use of foreign language.
Please disregard this
2014-03-03 10:21 GMT+01:00 Corinna Vinschen:
No, this is not mintty's fault. You have to understand that the
request for information from the DC is called before the actual
application had any chance to initialize, This happens before
the application has, in fact, been called from the Cygwin
Frank Fesevur writes:
2014-03-03 10:21 GMT+01:00 Corinna Vinschen:
- We allow the user to specify a timeout value and set the default to
1 second.
I think the [above] makes most sense. Maybe even keep the default
timeout on 3 seconds. When the user can change the value, it is up to
them
On Mar 3 12:29, Henry S. Thompson wrote:
Frank Fesevur writes:
2014-03-03 10:21 GMT+01:00 Corinna Vinschen:
- We allow the user to specify a timeout value and set the default to
1 second.
I think the [above] makes most sense. Maybe even keep the default
timeout on 3 seconds. When
Greetings, Corinna Vinschen!
I've just uploaded a new snapshot to http://cygwin.com/snapshots/
I've sent a reply with testing details, but it may have been caught by SPAM
deflection for excess use of foreign language.
Please disregard this notification, if a message will finally come
On Mar 3 18:47, Andrey Repin wrote:
Greetings, Corinna Vinschen!
I've just uploaded a new snapshot to http://cygwin.com/snapshots/
I've sent a reply with testing details, but it may have been caught by SPAM
deflection for excess use of foreign language.
Please disregard this
Greetings, Corinna Vinschen!
In the meantime, I see my previous mail was indeed caught in the middle. I'll
repost it with a link to test results.
Nah, never mind. I'm more interested of your experiences than in
dry numbers :)
Oh, don't be so quick, lady...
The results were quite
Greetings, Corinna Vinschen!
No, this is not mintty's fault. You have to understand that the
request for information from the DC is called before the actual
application had any chance to initialize, This happens before
the application has, in fact, been called from the Cygwin DLL.
On Mar 2 14:20, Frank Fesevur wrote:
2014-02-28 22:08 GMT+01:00 Corinna Vinschen:
That's not really a problem but a case of it is as it is. To get the
user and group info, Cygwin has to contact the DC and/or GC and then
runs into a timeout. Right now, the LDAP timeout is set to 3
Greetings, Corinna Vinschen!
I'd need to test it in domain environment, but I don't have access to one
with
Cygwin installed right now. Or, perhaps, I do?... let me check something.
Sure.
I just thought of a derelict pair of virtualbox containers, that were set up
to simulate domain
Greetings, Corinna Vinschen!
I'd need to test it in domain environment,
And with sane number of groups (less than 20), the results are barely
different between different caching strategies (less than 1%, which could
easily be explained by measurement error), except (again) for the case of
On 3/3/2014 08:52, Andrey Repin wrote:
I'd say it again, sane defaults are better, than alot of options.
Agreed in principle.
However, observe that all network stacks have a bunch of built-in
timeout options. They're rarely exposed to the user level, but their
defaults are typically quite
Greetings, Warren Young!
I'd say it again, sane defaults are better, than alot of options.
Agreed in principle.
However, observe that all network stacks have a bunch of built-in
timeout options. They're rarely exposed to the user level, but their
defaults are typically quite high.
On 3/3/2014 18:36, Andrey Repin wrote:
Once TCP session is established, it remains,
until closed or dropped on either end of the wire.
Have you done the packet capture to prove that Windows does in fact keep
the LDAP connection to the AD server up continually, or are you making
an
2014-02-28 22:08 GMT+01:00 Corinna Vinschen:
That's not really a problem but a case of it is as it is. To get the
user and group info, Cygwin has to contact the DC and/or GC and then
runs into a timeout. Right now, the LDAP timeout is set to 3 seconds.
I don't know yet if it's such a bright
Corinna Vinschen writes:
How? Details? Stackdump? It works for me(TM). The timing only shows
that it's not the right thing for you, or that in the long run the
non-caching option should just go away. For the time being, though, I
need *details*.
Sorry, that's the best I can do at the
On Feb 28 03:12, Andrey Repin wrote:
Greetings, Corinna Vinschen!
While we're at it, I just had this weird idea.
What if, as soon as the first Cygwin process in a process tree starts,
this process not only caches the primary group info, but also caches all
supplementary groups from the
On Feb 27 20:38, Corinna Vinschen wrote:
On Feb 27 20:06, Frank Fesevur wrote:
2014-02-13 15:38 GMT+01:00 Corinna Vinschen:
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
Corinna Vinschen writes:
1 second? That sounds still a bit slow.
It appears that that there are multiple DC involved, either via
delegation or redirection (as I've managed to get some partial group
resolutions where groups from a particular domain were absent). So all
this slowness probably
On Feb 28 16:45, Achim Gratz wrote:
Corinna Vinschen writes:
1 second? That sounds still a bit slow.
It appears that that there are multiple DC involved, either via
delegation or redirection (as I've managed to get some partial group
resolutions where groups from a particular domain were
Corinna Vinschen writes:
It allows you to do the following in /etc/nsswitch.conf:
db_cache: no
Using the 15:31 snapshot DLL again via VPN, id dumps core after about
2:30 minutes.
No caching of passwd and group data at all
db_cache: yes
Startup of a shell in mintty takes about 20
On Feb 28 20:49, Achim Gratz wrote:
Corinna Vinschen writes:
It allows you to do the following in /etc/nsswitch.conf:
db_cache: no
Using the 15:31 snapshot DLL again via VPN, id dumps core after about
2:30 minutes.
How? Details? Stackdump? It works for me(TM). The timing only
2014-02-28 18:14 GMT+01:00 Corinna Vinschen:
I made some tests myself today, while debugging Frank's problem. If I
I updated to the snapshot of today (28th) and now the message is not
shown anymore.
Thanks for the fix.
I have yet another observation. When I am not connected with VPN it
takes a
On Feb 28 21:53, Frank Fesevur wrote:
2014-02-28 18:14 GMT+01:00 Corinna Vinschen:
I made some tests myself today, while debugging Frank's problem. If I
I updated to the snapshot of today (28th) and now the message is not
shown anymore.
Thanks for the fix.
Thanks for the report.
I have
On Feb 28 22:08, Corinna Vinschen wrote:
On Feb 28 21:53, Frank Fesevur wrote:
2014-02-28 18:14 GMT+01:00 Corinna Vinschen:
I made some tests myself today, while debugging Frank's problem. If I
I updated to the snapshot of today (28th) and now the message is not
shown anymore.
Greetings, Corinna Vinschen!
I've just uploaded a new snapshot to http://cygwin.com/snapshots/
I've sent a reply with testing details, but it may have been caught by SPAM
deflection for excess use of foreign language.
Please disregard this notification, if a message will finally come through.
Greetings, Andrey Repin!
db_cache: no
Timer 2 Elapsed: 0:00:00,75
Stable (+-0.02 regardless of current credentials.)
My bad.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 01.03.2014, 02:27
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Corinna Vinschen writes:
[...]
With this patch applied, the aforementioned `id' now takes about 1.9
secs, in an otherwise identical scenario.
[...]
With this patch applied as well, `id' now takes constantly 0.4 secs.
Note that this speedup is only possible when fetching lots of group
Achim Gratz writes:
noldap
Sorry, copied the getgroups data again, this is the data for noldap of
course:
0.171u 0.015s 0:01.03 17.4% 0+0k 0+0io 3298pf+0w
0.093u 0.140s 0:00.97 23.7% 0+0k 0+0io 3292pf+0w
0.046u 0.093s 0:00.97 13.4% 0+0k 0+0io 3285pf+0w
0.062u 0.140s 0:00.97 20.6%
Hi Achim,
thanks for testing.
On Feb 27 09:07, Achim Gratz wrote:
Achim Gratz writes:
noldap
Sorry, copied the getgroups data again, this is the data for noldap of
course:
0.171u 0.015s 0:01.03 17.4% 0+0k 0+0io 3298pf+0w
0.093u 0.140s 0:00.97 23.7% 0+0k 0+0io 3292pf+0w
Corinna Vinschen corinna-cygwin at cygwin.com writes:
1 second? That sounds still a bit slow. Considering that I'm now
member of 414 groups, and you are member of 440 groups, the extra number
of groups cannot account for that.
This sounds surprisingly as if the
names of some of your
On Feb 27 12:54, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
1 second? That sounds still a bit slow. Considering that I'm now
member of 414 groups, and you are member of 440 groups, the extra number
of groups cannot account for that.
This sounds
2014-02-13 15:38 GMT+01:00 Corinna Vinschen:
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the latest
bugfix.
I noticed another thing. Not
Greetings, Frank Fesevur!
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the latest
bugfix.
I noticed another thing. Not sure if I would
On Feb 27 20:06, Frank Fesevur wrote:
2014-02-13 15:38 GMT+01:00 Corinna Vinschen:
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the
On Feb 27 23:15, Andrey Repin wrote:
Greetings, Frank Fesevur!
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the latest
bugfix.
Greetings, Corinna Vinschen!
1 second? That sounds still a bit slow. Considering that I'm now
member of 414 groups, and you are member of 440 groups, the extra number
of groups cannot account for that.
This sounds surprisingly as if the
names of some of your groups are not cached
Greetings, Corinna Vinschen!
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the latest
bugfix.
I noticed another thing. Not sure if
Sorry, I don't grok this. What has a web application server to do with
asking a DC for user info?
We have one of these that does a lot of DC lookups because it authenticates
all users. It's also in a much faster network, so I can check there what
the lookup rate could be reasonably expected
On Feb 26 06:17, Andrey Repin wrote:
Greetings, Corinna Vinschen!
Other than that, I just had an in-shower inspiration how to speed up
`id' specificially. The getgroups(2) call is in the center of this and
I could probably speed up the stuiff a lot by opening the LDAP
connection in
On Feb 26 08:09, Achim Gratz wrote:
Sorry, I don't grok this. What has a web application server to do with
asking a DC for user info?
We have one of these that does a lot of DC lookups because it authenticates
all users. It's also in a much faster network, so I can check there what
the
On Feb 26 11:02, Corinna Vinschen wrote:
On Feb 26 08:09, Achim Gratz wrote:
Sorry, I don't grok this. What has a web application server to do with
asking a DC for user info?
We have one of these that does a lot of DC lookups because it authenticates
all users. It's also in a much
Corinna Vinschen writes:
I just created 400 groups in AD, and added myself as member. An `id' on
a 32 bit Windows 7 domain member machine in my tiny network consisting
only of a handful of Windows VMs and with me as the only real user takes
about 3.6 secs with the latest code from CVS, using
Corinna Vinschen writes:
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the latest
bugfix.
I've tested the 2014-02-19 snapshot at work.
Greetings, Achim Gratz!
2. I use a few volumes on NetApp filers that have security set up so
that you can't change attributes. That means POSIX permissions are
always listed as .
That seems like a bug elsewhere. Being able to change permissions shouldn't
restrict you from requesting
Andrey Repin writes:
That seems like a bug elsewhere. Being able to change permissions shouldn't
restrict you from requesting them.
There is no bug, not in Cygwin nor anywhere else. The standard file
attributes are all cleared and since I can't set any of them (a policy
which gets inherited)
On Feb 25 19:14, Achim Gratz wrote:
Corinna Vinschen writes:
This is a pretty intrusive change, in need of some serious testing, so
I'd like to ask for volunteers. The latest 2014-02-13 snapshot from
http://cygwin.com/snapshots/ contains the changes, including the latest
bugfix.
I've
Corinna Vinschen writes:
The stuff in the `id' application is not cached at all. Caching is
inherited from the parent process, but the parent never asked for all
your groups so it hasn't cached this information. Every invocation of
id has to request the group info anew.
OK, then I was
On Feb 25 21:25, Achim Gratz wrote:
Corinna Vinschen writes:
The stuff in the `id' application is not cached at all. Caching is
inherited from the parent process, but the parent never asked for all
your groups so it hasn't cached this information. Every invocation of
id has to request
Greetings, Corinna Vinschen!
Also, more radically, if we drop the functionality to define another
group name for a group, we could drop the requirement to open an LDAP
connection to fetch group information to the DC entirely(*). This would
only affect domain groups, local groups could still
Greetings, Corinna Vinschen!
Other than that, I just had an in-shower inspiration how to speed up
`id' specificially. The getgroups(2) call is in the center of this and
I could probably speed up the stuiff a lot by opening the LDAP
connection in getgroups only once.
Isn't local SAM
On Feb 17 17:21, Corinna Vinschen wrote:
On Feb 13 15:38, Corinna Vinschen wrote:
Hi folks,
this week I applied the first incarnation of the new passwd/group
handling code to the Cygwin repository and after fixing a crash which
manifested in Denis Excoffier's network, I think we're
On 2/21/2014 9:55 AM, Corinna Vinschen wrote:
- You want to specify a different login shell than /bin/sh.
Typo: You forgot to change /bin/sh to /bin/bash.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On Feb 21 11:11, Ken Brown wrote:
On 2/21/2014 9:55 AM, Corinna Vinschen wrote:
- You want to specify a different login shell than /bin/sh.
Typo: You forgot to change /bin/sh to /bin/bash.
Ken
Fixed, thank you.
Corinna
--
Corinna Vinschen Please, send mails regarding
On Feb 19 21:58, J.H. vd Water wrote:
Hi Corinna,
Can you please just test the today's snapshot which should show up
soon on the http://cygwin.com/snapshots/ page.
Like Andrey I tested the 19/2 snapshot of today (x86).
For good measure, I again started afresh ...
getpwent (db_enum:
Hi Corinna,
What I meant was:
The output of 'id' in my regular setup shows:
@@# id
uid=1003(Henri) gid=513(None)
groups=513(None),0(root),544(Administrators),545(Users)
The output of 'id' in the test setup shows:
$ id
uid=1003(Henri) gid=513(None)
On Feb 20 12:24, J.H. vd Water wrote:
Hi Corinna,
What I meant was:
The output of 'id' in my regular setup shows:
@@# id
uid=1003(Henri) gid=513(None)
groups=513(None),0(root),544(Administrators),545(Users)
The output of 'id' in the test setup shows:
$ id
Hi Corinna,
Now that the XP bug is out of the way ... I would like come back to the
change in
the output of 'id'.
Obviously, everything after '545(Users),' in the output of 'id' are
well-known
concepts (Windows) to you (but, not to me) ...
I explained that in my mail and I already wrote
On Feb 20 14:28, J.H. vd Water wrote:
I don't know about you, but on my Linux box I get something like this:
$ id
uid=500(corinna) gid=11125(vinschen) groups=11125(vinschen),33(tape),
100(users),107(qemu),486(wireshark),1000(cvs),11126(libvirt)
Most of the time I don't care about
On Feb 19 23:57, Andrey Repin wrote:
Greetings, Corinna Vinschen!
[1] http://linux.die.net/man/1/getent
That sounds pretty much like the tool we need to be able to get rid of
the `grep /etc/passwd' stuff we have in some of the service configuration
helper scripts. Unfortunately it's
Greetings, Corinna Vinschen!
[1] http://linux.die.net/man/1/getent
That sounds pretty much like the tool we need to be able to get rid of
the `grep /etc/passwd' stuff we have in some of the service configuration
helper scripts. Unfortunately it's a glibc tool so we probably have to
Hi Corinna,
However, as you know, the supplementary group to which I referred above do
NOT show
up in my /etc/group file on Cygwin (they show up in SAM ... somewhere).
... and I do not care, as these groups are NOT relevant to me as a
Cygwin-only user
of the Windows operating system
On Feb 20 19:58, J.H. vd Water wrote:
Hi Corinna,
However, as you know, the supplementary group to which I referred above do
NOT show
up in my /etc/group file on Cygwin (they show up in SAM ... somewhere).
... and I do not care, as these groups are NOT relevant to me as a
Hi Corinna,
If you only want to use the content of your passwd and group files,
rather than the db (which is pretty much upside down from what this
patch is trying to accomplish, but, anyway), simply change your
/etc/nsswitch.conf file accordingly. Just as on Linux.
:-) My
2014-02-15 13:52 GMT+01:00 Corinna Vinschen:
Just tested and copied .bashrc to .profile and that solved the problem.
Good, so it was really just a shell thingy.
I vote[1] for /bin/bash being the default shell.
Done in CVS.
Just downloaded the 2014-02-18 snapshot, deleted that .profile and
On Feb 18 21:02, J.H. vd Water wrote:
Hi Corinna,
The crash looks weird. It looks like your machine doesn't return
the machine sid when it's requested. Can you please run the following
test application as non-admin and as admin and paster the output for
both cases into your reply? Hmm,
Hi Corinna,
(Sorry, have't found time to properly subscribe to the list, yet)
Both cases show the same output:
$ ./lsa
pdom name: WORKGROUP dnsname: (null), sid: 0x0
adom name: XP sid: 0x246058
I lied here :-) The non-admin case showed: ... sid: 0x246060
(So, almost the same)
Huh. This
Greetings, Corinna Vinschen!
this week I applied the first incarnation of the new passwd/group
handling code to the Cygwin repository and after fixing a crash which
manifested in Denis Excoffier's network, I think we're at a point
which allows to push this forward.
[...]
Ok guys, I just
Greetings, J.H. vd Water!
Both cases show the same output:
$ ./lsa
pdom name: WORKGROUP dnsname: (null), sid: 0x0
adom name: XP sid: 0x246058
I lied here :-) The non-admin case showed: ... sid: 0x246060
(So, almost the same)
Yeah, I understand, they supposed to be different.
Mine's also
Hi Andrey,
I'm going to make some tests on XP, but if I can't track this down,
would you mind if I send you a test Cygwin DLL with extended debug
output to help tracking it down?
The best thing to do, I believe, if you want to fix 'XP' (my machine may
turn out
to be a misfit).
However, I
On Feb 19 18:56, Andrey Repin wrote:
Greetings, Corinna Vinschen!
this week I applied the first incarnation of the new passwd/group
handling code to the Cygwin repository and after fixing a crash which
manifested in Denis Excoffier's network, I think we're at a point
which allows to
On Feb 19 12:01, J.H. vd Water wrote:
Hi Corinna,
(Sorry, have't found time to properly subscribe to the list, yet)
Both cases show the same output:
$ ./lsa
pdom name: WORKGROUP dnsname: (null), sid: 0x0
adom name: XP sid: 0x246058
I lied here :-) The non-admin case showed: ...
Greetings, Corinna Vinschen!
Setting
db_enum: local
seems to be really destructive.
I'm not good at reading straces, so... Can I make a useful trace for your
inspection?
So far, I'm unable to start anything with freshly rebuilt Cygwin1.dll
if db_enum set to local. Even uname -a
On Feb 19 23:19, Andrey Repin wrote:
Greetings, Corinna Vinschen!
Setting
db_enum: local
seems to be really destructive.
I'm not good at reading straces, so... Can I make a useful trace for your
inspection?
So far, I'm unable to start anything with freshly rebuilt Cygwin1.dll
Greetings, Corinna Vinschen!
[1] http://linux.die.net/man/1/getent
That sounds pretty much like the tool we need to be able to get rid of
the `grep /etc/passwd' stuff we have in some of the service configuration
helper scripts. Unfortunately it's a glibc tool so we probably have to
create
Hi Corinna,
Can you please just test the today's snapshot which should show up
soon on the http://cygwin.com/snapshots/ page.
Like Andrey I tested the 19/2 snapshot of today (x86).
For good measure, I again started afresh ...
getpwent (db_enum: local) no longer crashes. Splendid!
Henri
--
this week I applied the first incarnation of the new passwd/group
handling code to the Cygwin repository and after fixing a crash which
manifested in Denis Excoffier's network, I think we're at a point
which allows to push this forward.
[...]
Ok guys, I just applied a patch implementing
1 - 100 of 156 matches
Mail list logo
