From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) by sourceware.org (Postfix) with ESMTPS id 9134D3858C53 for ; Thu, 24 Aug 2023 16:27:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9134D3858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-1a28de15c8aso4651748fac.2 for ; Thu, 24 Aug 2023 09:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692894435; x=1693499235; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UJTqFbth+9H+8KdHKXt96oq8NXZLxp8Ut2V/or9RiHE=; b=lZhsJo1XRtJuEqfRZCxSMU5zltUdVxVE+Lr9DGVDg2PVqcGFusPWchlJdpbPONddMA TivUMhqbNpDpYS1BguCheA0/B3BP3VmLDvU7qx1oshyZkAglIe41Q9uZM7pm1Iv0Xtsj 142DA2kA7BguQA5siLpV7UmrQiMtfpa/lJN0EjCoJQ0R0tzaOPdM3BXeJ6+GmFBYZL9u yEOdS/MwD9wi3a+e+Pe4ejY/LRyBo5qEHDMgHmtq4MsqKq/nOFmK/TqMRXbMV3UYV5Vs 5C8vbyeLlBrUeTkAQUzqlXR+MpyfzX1Z2iJwIiyYZeLr9n3Kgq1HL5Aeqz7crlR7Z+OB QT0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692894435; x=1693499235; h=content-transfer-encoding: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=UJTqFbth+9H+8KdHKXt96oq8NXZLxp8Ut2V/or9RiHE=; b=PB/qmdsNJ2Kdf7Yb/uMaqPPu6drVZFxEJEFD34He8VrHEf8WyReg4UqoZMDvUDpREq 6rS/n42/2Qm/G6XnpKixb/t87XuY4XMV2QowkucfQI8vEUX6+xBBtQ2PpyU9HTJIQZTe 0V0FPS4ZP1zkDElN09dbsmoCVbhqjxemc+ZEaDACAFDs9+HyV0UXvIUI+wMstmcSpFJh Sld6ulcZ1p2AfXKueN28r9670XHzq/e6njanwlP5l2vda06tR0SYKEoaFRlUnkVQbFJn Bncyqs3Ut6XoaFMWfydZfUfS86VU/R9P1dPZshgmcIuxu1mmlLDjGGf4h4xKqTOFPF/o +5aQ== X-Gm-Message-State: AOJu0YyHYhCkU/tY0HbFVOPkM+RzsBv8HVYEpLryKT5DF+VdJZm4BXI9 dbVEk0pq0l8EJvoePdsvAhzckvKSnG0VtQ6tg6XIaAcsPFM0zA== X-Google-Smtp-Source: AGHT+IFh1eR3ICrVmfnbo1ZXwqWFZlft0vzfnxNJ2Ju0RROpbw4250a4FCUmxPSDo9+jMRHl7o+BZcj2p3ThToKQhi4= X-Received: by 2002:a05:6870:e749:b0:1b3:cb1f:cd1f with SMTP id t9-20020a056870e74900b001b3cb1fcd1fmr378600oak.0.1692894434665; Thu, 24 Aug 2023 09:27:14 -0700 (PDT) MIME-Version: 1.0 References: <00cd8659-a17a-c5c6-0205-9b510859f95e@Shaw.ca> In-Reply-To: <00cd8659-a17a-c5c6-0205-9b510859f95e@Shaw.ca> From: Martin Wege Date: Thu, 24 Aug 2023 18:27:03 +0200 Message-ID: Subject: Re: Cygwin pathconf() query filesystem kernel data? Re: How does Cygwin detect MSFT NFSv3 file system? Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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,KAM_SHORT,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 List-Id: On Tue, Aug 22, 2023 at 12:07=E2=80=AFAM Brian Inglis wrote: > > On 2023-08-21 06:03, Martin Wege via Cygwin wrote: > > On Sat, Aug 19, 2023 at 7:50=E2=80=AFPM Brian Inglis wrote: > >> > >> On 2023-08-18 07:09, Martin Wege via Cygwin wrote: > >>> On Fri, Aug 18, 2023 at 10:44=E2=80=AFAM Corinna Vinschen via Cygwin > >>> wrote: > >>>> > >>>> On Aug 17 20:49, Martin Wege via Cygwin wrote: > >>>>> On Mon, Aug 14, 2023 at 10:56=E2=80=AFPM Corinna Vinschen via Cygwi= n > >>>>> wrote: > >>>>>> and the result is the same. Note that Cygwin supports MSFT NFSv3 = but > >>>>>> not CITI NFSv4.1 internally. No gurantee that Cygwin always does = what > >>>>>> is necessary for that other NFS. > >>>>> > >>>>> 1. How does Cygwin detect whether something is a MSFT NFSv3, or not= ? > >>>>> Cygwin /bin/mount lists the CITI NFSv4.1 as 'nfs', so there *IS* > >>>>> something which detects that? > >>>> > >>>> The filesystem name returned by NtQueryVolumeInformationFile is "NFS= ". > >>>> If any other NFS returns the same filesystem name, it will be treate= d > >>>> just like MSFT NFSv3. > >>>> > >>>>> 2. Are Cygwin soft link handing depend on MSFT NFSv3 or not, i.e. d= oes > >>>>> the Cygwin soft link code behave differently for MSFT NFSv3 file > >>>>> systems? > >>>> > >>>> Yes. NFS doesn't support symlink creation and symlink reading via > >>>> the usual functions, because Windows symlinks are created as reparse > >>>> points. NFS doesn't support reparse points. So the developers of > >>>> the MSFT NFS client had to invent their own way to create and > >>>> read NFS symlinks: > >>>> > >>>> https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dwinsu= p/cygwin/path.cc;hb=3DHEAD#l1719 > >>>> > >>>> https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dwinsu= p/cygwin/path.cc;hb=3DHEAD#l2750 > >>>> > >>>>> 3. Does Cygwin implement the pathconf() api? > >>>> > >>>> Yes. Surprisingly, you can check this yourself by just calling the > >>>> function and trying to compile your code. > >>> > >>> Apologies, how do we say in German? "Ich sollte meine Frage konkretis= ieren:" > >>> > >>> Does the Cygwin implementation of pathconf() support query data of th= e > >>> underlying filesystem based on data from the kernel, as UNIX does? So > >>> pathconf() returns different values for NTFS, ReFS, or Windows builti= n > >>> NFSv3? > >>> > >>> I am asking, because as far as I know the Linux implementation is not > >>> a syscall, and instead glibc guesses values based on builtin static > >>> data, and whatever fstatfs() has to offer. Compared to that UNIX > >>> (Solaris, AIX, HPUX, ...) have pathconf() as a syscall, and actually > >>> ask the filesystem itself. > >> > >> Many library functions are implemented as documented either in the Cyg= win > >> packages cygwin-doc and man-pages-posix available for installation; an= d use as > >> e.g. `man 3p fpathconf`, also available online at: > >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.h= tml or > >> https://man7.org/linux/man-pages/man3/fpathconf.3p.html > >> and for comparison and reference we make Cygwin package man-pages-linu= x > >> available for installation; and use as e.g. `man -m linux 3 fpathconf`= , also > >> available online at: > >> > >> https://man7.org/linux/man-pages/man3/fpathconf.3.html > >> > >> suggestions for setup are in the package announcements made every 9-12= weeks > >> when the latest Linux man-pages package is released and updated on Cyg= win. > >> > >> Please also note that the getconf(1) program is installed as part of C= ygwin and > >> can access f/pathconf variables associated with a pathname argument, a= s shown in > >> getconf(1) `man 1 getconf` and getconf(1p) `man 1p getconf`. > > > > Thanks, but my question was about the Cygwin *implementation*: Does it > > distinguish between NTFS, REFS, FAT, NFS? Does it use data obtained > > from the Windows kernel at runtime, or does it rely on static data > > compiled into the cygwin.dll library? > > My suggestion was to encourage you to try out the command on the relevant > filesystems, or feel free to check out the repo and the implementation. Where in the git is the implementation of pathconf()? Thanks, Martin