X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=WpIAXwIGyTKm3OQG4FDWYuwWcC2i
	h/v+qi69m6OtngKi/r3nMgalQi3R0de9jLxZQreZdUrysiuoBgGVraZW7uJwm8wd
	gdII1yYBMspNNKd/QkwcRYkjQttioKO/tHipWlprYPpf9dHirjn4d5whJ6fY691r
	Fn4uSSWM0rdj3Fc=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=kqPNUB5k9V1GdyI8BU5pXG2tel8=; b=ih
	zDKpd21IES3A/RYO1Z+fhw2qaECZ+2WxwVHNBLij6aehcCA2QBd6TOQbbSp1JtOF
	oLU78OSxru5UHxjwF98oDKJpLE43fyuG/8oiNnYmmPFsJ4y0MXGi8fu79Rqu1j3O
	TBiXhgUHsOlD8Gqe/ULX1emLlWeVQH24VSamNOyUE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO:	smtp6-g21.free.fr
Mime-Version:	1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject:	Re: timeout in LDAP access
From:	Denis Excoffier <cygwin AT Denis-Excoffier DOT org>
In-Reply-To:	<20140716135151.GC8520@calimero.vinschen.de>
Date:	Thu, 17 Jul 2014 08:33:16 +0200
Message-Id:	<4457DF49-B4C7-4A7C-A189-AB6F4D94794E@Denis-Excoffier.org>
References:	<E760D646-FFCB-434C-B990-7783DC011326 AT Denis-Excoffier DOT org> <20140625211355 DOT GA25116 AT calimero DOT vinschen DOT de> <E3509AAC-C4A0-4293-988F-E94BF2421180 AT free DOT fr> <20140707110714 DOT GJ1803 AT calimero DOT vinschen DOT de> <19B9F8D8-7FD6-4A7B-AC83-BBF8D152319D AT Denis-Excoffier DOT org> <20140709101256 DOT GD26447 AT calimero DOT vinschen DOT de> <BA09D7D8-96E6-431F-9434-8BA8A2AB4952 AT Denis-Excoffier DOT org> <20140714095107 DOT GB10401 AT calimero DOT vinschen DOT de> <20140714134836 DOT GA2637 AT calimero DOT vinschen DOT de> <79A8CE40-E412-4479-B058-378823313FA8 AT Denis-Excoffier DOT org> <20140716135151 DOT GC8520 AT calimero DOT vinschen DOT de>
To:	cygwin AT cygwin DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id s6H6XiMt028683

On 2014-07-16 15:51, Corinna Vinschen wrote:
> It occured to me that there's another way to do that.  The problem
> you're mentioning above could be alleviated if the first Cygwin process
> in a process tree fetches all POSIX offsets of all trusted domains right
> at the start, rather than fetching the POSIX offsets only on demand by
> whatever process needs it.  This would slow down the startup of the
> first process slightly (one LDAP request per trusted domain, but only
> asking your primary DC), but this would have two advantages:
> 
> - After fetching all POSIX offsets, we could filter out all POSIX
>  offsets which don't make sense.  These would be set using the fake
>  offset setting mechanism.  "No sense" would include offsets < 0x110000
>  or offsets > 0xff000000.  If the first process in the tree 
> 
> - The UID/GID values would be stable throughout the process tree.
> 
> - The UID/GID values would be stable systemwide when utilizing cygserver.
> 
> That's a bit of work, but Cygwin 1.7.31 will still come without this
> AD integration code anyway, so we still have time to turn everything
> upside down.
I buy this of course, but i’m still not convinced that we have to
workaround. After all, since i don’t care the other domains in my daily
work, i’m not affected at all. Most of the users will never be affected
i suppose. And if Cygwin happens to circumvent a null posixOffset by
providing its own, there will be even less chances for collisions and
for collisions being reported.

But we can consider the other way and for that i will use a comparison:
using special characters (like ‘\n’) gratuitously in the middle of filenames
is usually considered as a bad practice, but always possible by
doing ‘char *filename = "a\nb"; fopen(filename, "w")’. Now, once this
file is created, you can use ‘ls’ in the folder. Do you think ‘ls'
should respect user decision and display the raw \n in its output or
try to workaround by using some substitution character (like ‘?’) in order
not to wrap at unexpected locations? The answer is that ‘ls’ substitutes
by default, but also provides a full group of related options to change this
behavior (--quoting-style=WORD, --hide-control-chars).

Of course, adding options (eg in nsswitch.conf) to orientate the assignment
of posixOffsets to various substitutes would be useless. Even assigning
the null posixOffsets to non-null values, i’m not convinced of.

Denis Excoffier.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -