From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id A08CE385828F for ; Mon, 18 Dec 2023 12:05:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A08CE385828F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A08CE385828F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::533 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702901115; cv=none; b=kLubxRsWL372TxzUIyVmzZXjA98DkYr6uYpeUEX3TacTzG8wq01t3aTlNn6EfqGE6SeD6x3eEiwFmkKcCRIzDVQWIY9y1I10zqaz4LXVOwQEZI+G654IE9o2cXvZpnUe99Ca+lhZeuzY+9DyGYoTPp6rcz5frZzSHqy9V1I48gM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702901115; c=relaxed/simple; bh=BNKAwU8Uk4NKUBpoMZs6gkGClXutwkpb3pV8EKENy10=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=t0gGCq2Easq1dhapdoRcz2VgY9vxOxtw7fvCQfMDvl3lvA76DLEe6X0DPcjLaUWYB/CNVXo+DToSQPsIan1Az/rBJmez1GZAzKWasxUCZaEimq49deBlPW6I+1Gro5vd7By+kX9Ey62QJ1c0IUgTixqSL3MnvcwlX6cagRk4P4I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-54c7744a93fso3578723a12.2 for ; Mon, 18 Dec 2023 04:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702901105; x=1703505905; darn=cygwin.com; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=DRd/GZqW+uZRV6fufAYvvHgccLBr/GaCjvUi/PPIHvY=; b=NNtzVg74OZo7Las8S95034uE3fDTjXRC4MvzdmMW+HK6wOIW72aYJqMhuGlJKIh+C+ Yd4uGBI6NvuKylhuKS3SQeVB3Y3dQJOqyg9BJ1CZLht8GKQamj56YleMffJkw7K+o/xS GM6lZVLeGGoiMmYsDtfaihkpOkq9a5nbXJUZDD19WU6imXQ7tRC3ki+4NdMt34+yc4eK Ufnl/k12BVppEDlGVkDZ3XA2++ILn6BYdB2tlb9QBVDPk4PUiR+FE48QSvHxjLPo4pko rJQ8npsoeqeYywl6erWiji4RNC+OkiZpGH69T23CuLwehA1SExMt3Qw3601xynKkuv2V 3gAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702901105; x=1703505905; 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=DRd/GZqW+uZRV6fufAYvvHgccLBr/GaCjvUi/PPIHvY=; b=HHxeKoPXZWB97avh0IHIw8KTj5RWwSGz/jQCpG2z5K1PBMl2yxmEOfU9RKVwn3jV2l F2sZ+mt5bMxXMq2iAZ4jFI0s9wPL5mih/ArzRMQAhHgyppK6sZ16H7P5vrQleAy3fx4R Ow7LSgKlUF+xzkCXsyOHQJXsiDqI9kroX20hFGCKOyYpeDo2IWQlDqfjbspmiDm/B3a3 PZ9tw8JE3w2a3bu34PA86W+wKIblBe0JVvLwD6geQcP6QkhYRK2RwMbCByGusw1aRzJi 4YQ7bOvE4B3jSKt3IAUINEvuVZHY+z5vbnOv3sMnRpM2VfkBp2cdzV6aN8F1ff10iFtW Qrcg== X-Gm-Message-State: AOJu0Yxfr2OPB52EF83yr2DwnN4Ag0DJowvcmUeYPj91P8k8EobDjYyJ 8JRzJbt99V88G7ajgnXUyDB+LxvfyCcjgOopIUDGoh7rvWE= X-Google-Smtp-Source: AGHT+IFTRka0l7psQPGeeIYfpB1qqSzFRuQmlLoTRaCUK1ShPplNU2HcqQ35OBe5dt57H3S5J1SADuUd1M9rpcdkomo= X-Received: by 2002:a50:9b5d:0:b0:553:6c38:148a with SMTP id a29-20020a509b5d000000b005536c38148amr408711edj.39.1702901104789; Mon, 18 Dec 2023 04:05:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Cedric Blancher Date: Mon, 18 Dec 2023 13:04:00 +0100 Message-ID: Subject: Re: Cygwin generates syscalls for *.lnk files on filesystems with native symlink support? To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.5 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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 1 Sept 2023 at 13:00, Corinna Vinschen via Cygwin 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. Why? If you have the path name you could lookup the (cached) mount points, and determine the filesystem type. Same solution applies for UNC paths, where you can easily lookup the filesystem type, and cache it per-process or in Cygserver. > 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. Can this machinery please be turned off via CYGWIN env var option? As discussed in https://www.mail-archive.com/cygwin@cygwin.com/msg174547.html this machinery causes very bad filesystem lookup performance, and it would IMO a good idea to have an option to turn this off, and just allow and expect native links (for NTFS, ReFS and NFS). Maybe CYGWIN env var option winsymlinks_expect:native? winsymlinks_expect takes a : seperated list which symlink types are to be expected. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur