public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Cedric Blancher <cedric.blancher@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin generates syscalls for *.lnk files on filesystems with native symlink support?
Date: Mon, 18 Dec 2023 13:04:00 +0100	[thread overview]
Message-ID: <CALXu0Ue9SyJod+0k24pQzs3KPg1RPquRfhN3tw3GYG-qMt_+DQ@mail.gmail.com> (raw)
In-Reply-To: <ZPHDrz7VedOBROtT@calimero.vinschen.de>

On Fri, 1 Sept 2023 at 13:00, Corinna Vinschen via Cygwin
<cygwin@cygwin.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.

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 <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

  parent reply	other threads:[~2023-12-18 12:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-01  4:23 Cedric Blancher
2023-09-01 10:57 ` Corinna Vinschen
2023-09-26  5:12   ` Cedric Blancher
2023-12-18 12:04   ` Cedric Blancher [this message]
2024-01-08 13:56     ` Corinna Vinschen
2024-01-08 17:11       ` matthew patton
2024-01-08 18:11         ` Corinna Vinschen
2024-01-08 18:44           ` matthew patton
2024-01-08 19:05             ` Rainer Emrich
2024-01-08 19:17             ` Jeffrey Altman
2024-01-08 19:21               ` Corinna Vinschen
2024-01-08 19:57               ` matthew patton
2024-01-08 20:27                 ` Brian Inglis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALXu0Ue9SyJod+0k24pQzs3KPg1RPquRfhN3tw3GYG-qMt_+DQ@mail.gmail.com \
    --to=cedric.blancher@gmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).