On Mon, Jan 8, 2024 at 2:56 PM Corinna Vinschen via Cygwin <cygwin@cygwin.com> wrote: > > On Dec 18 13:04, Cedric Blancher via Cygwin wrote: > > 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. > > No can do. > > We *do* filesystem info caching, but this requires to be able to > open the file in the first place. If the file exists, we're done, but > if not, we have to evaluate all symbolic links in the path first. > Simply reducing the path to the mount point and then translate it into > a Windows path doesn't cut it. > > After the file (or its parent dir) could be opened, so we know the path > is valid, we can fetch the filesystem info right from the open file > handle. At this point, we can shortcut the whole thing, reducing > the three necessary calls to kernel functions to only the first one > and skipping all the filesystem evaluation code. > > > > 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. > > We won't add any more options to the CYGWIN env variable if it's not > necessary, and there's no proof at all that this is necessary in this > case. > > If the file exists as specified, there will be no further check for > .exe or .lnk. If it doesn't exist, *and* the return code from > the kernel is STATUS_OBJECT_PATH_NOT_FOUND (or any one of a > number of equivalent return values) we're done here and are going > to fall back to checking for symlinks in the leading path components. > > If we got over that, the check for .exe is unavoidable. [snip]
What about doing lookups in parallel, e.g. use |NtCreateFile()| with an |IO_STATUS_BLOCK|, and do lookups for *.exe, *.lnk etc. in parallel ? That might not help for all filesystem drivers, but some of them are multithreaded (e.g. SMB, ms-nfs41-client, ...) and would greatly benefit from that since the requests would go async&¶llel over the network, instead of sequentially like it is now. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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
