X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D583638560A7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1695705240;
	bh=PmjUMK2uRMzxML0jV3L0Bi7kCac92iH+L2LVZPJ5a/8=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=S95NmaRrwsJgSFDY8NJUD0KVL93z9nH0sbnAo60EGTfE0AJqlhqyRufXSs/WWWcEw
	 9IsaD6WYX8MvbjAQCFLRPLamGLD5Kqb2Kozy/R3LnoiWRgWIy3Uz12LIT2GMjCQYbQ
	 rVcMRqMO6OlP0aGafrfhTDjBdRQOrzZn03lDu93o=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E76803858C2A
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1695705191; x=1696309991;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=ndyfzqXXPU/xoYAb8RmpA15JAX8KDu2CP8gsIldfsCM=;
 b=Z5zOiop0gbVZKOYbyvVCzL3eybDMqEw/cP23d+A7C+ucrzd5kYLnQQB0bnh7ymMJ7t
 /UHnVct/THcEJGwCeoqZGbLJ6IgggzMaerLv5F2eT45ci8KyaY7zkmzAv7GLmCZWd3E8
 hu5jjWO1VCJmJw5bny7LZouikv1OW5kx/1QcQ5Hwi6xIiCNRGDq2ERwj5dxjZ7ME0ICK
 yfh0VGofT42u5SRY0Ot6MJ8bbBDWBN5vL0hN5+IwR0NO8k0QP8wBQxxGhgKkrP9Biqf+
 yNeZkrCaQJpeLGAakYVZYv8dgwfbS1ExksxS6NFslZG67k0k8VxbP4FsVlZ+9WvRxd32
 ARcw==
X-Gm-Message-State: AOJu0YwHHMMD+rDKq09s5eyTUJQhFtsY/qcY7id7+ATOdlRl+gFegSCc
 f1wfcXZ1hteM7NyoZ08v+7LiKT9NTO0arXC/5ApPQBJqVlA=
X-Google-Smtp-Source: AGHT+IGqUst7yDpF6MCMmzBw5T2GcB652XH0gKM92BLyEGjzhU2kcpt57Tu6Li8lHiwELr3V5V6EL8uV44ts5k6F4b8=
X-Received: by 2002:ac2:515c:0:b0:501:c1d4:cf68 with SMTP id
 q28-20020ac2515c000000b00501c1d4cf68mr7924474lfd.15.1695705191389; Mon, 25
 Sep 2023 22:13:11 -0700 (PDT)
MIME-Version: 1.0
References: <CALXu0UfRxk5G=3OjbwoNFW7xSj1rHTNw5giS6YZb9p1gF5ceTA AT mail DOT gmail DOT com>
 <ZPHDrz7VedOBROtT AT calimero DOT vinschen DOT de>
In-Reply-To: <ZPHDrz7VedOBROtT@calimero.vinschen.de>
Date: Tue, 26 Sep 2023 07:12:35 +0200
Message-ID: <CALXu0UfsDUrMX6197RFH4JsZtW8GnOdztrCu8TKZCyCgapvHNA@mail.gmail.com>
Subject: Re: Cygwin generates syscalls for *.lnk files on filesystems with
 native symlink support?
To: cygwin AT cygwin DOT com
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Cedric Blancher via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Cedric Blancher <cedric DOT blancher AT gmail DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Fri, 1 Sept 2023 at 13:00, Corinna Vinschen via Cygwin
<cygwin AT cygwin DOT com> wrote:
>
> On Sep  1 06:23, Cedric Blancher via Cygwin wrote:
> > Good morning!
> >
> > During a Cygwin 3.4.8-1.x86_64 debugging session I noticed something
> > odd when I looked at the network traffic generated by one of our
> > cluster nodes:
> > It seems that for each call to a tool (i.e. starting "sed" from
> > "bash") Cygwin searches for *.lnk files.
> >
> > Is this correct even when the filesystem in question has native
> > symlink support (e.g. NFS)?
>
> Yes.  During file handling, Cygwin doesn't know what filesystem a
> file is on until it could actually open the file and request file
> and filesystem info from the open handle.  So if Cygwin couldn't open
> "foo" because the NtCreateFile call returned with status
> STATUS_OBJECT_PATH_NOT_FOUND or STATUS_OBJECT_NAME_NOT_FOUND, or
> STATUS_NO_SUCH_FILE, or one of the countless other status codes the
> kernel (or the driver) might return in case a file doesn't exist,
> it will tack on .lnk and .exe and, for historical reasons, .exe.lnk,
> and try again.

Our concern here is that this produces an absurd amount of extra
syscalls (6x more!!, compared to native POSIX), which hurts CIFS and
NFS performance.

The example with calling sed in a script is especially BAD, as trying
to execute "sed" in a bash shell script leads it try for sed.exe,
sed.sh, sed.bat, multiplied by looking for *.lnk files (i.e.
sed.exe.lnk, sed.sh.lnk, sed.bat.lnk).

And what finally made my brain go BOOM was the (IMO) absurd
combination like "sed.bat.exe.lnk"

Ced
-- 
Cedric Blancher <cedric DOT blancher AT gmail DOT com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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