DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 49TFm7eR2736351
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=P5lhi+kj
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 025E13858404
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1730216886;
	bh=+WFcl8CdtI/Lt7YD5dZJVTC1x4DIl9PiUoUjN/68PYM=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=P5lhi+kjVmtadLcA4HRnfFXMchN8gS1ClTAmuZMsAQrBrL4RVNqX8ubUxEgKbcf8w
	 kQqNA7aj7YkNNI+xhjOgOPVNwjwyjfi6rFT1dGj0pngZp6ZNMZp0kbg0ZgEJK3Gr/P
	 8y+7vXNiyoafM0EqQ1+KkzJOZnwJq7fXjLyeKfno=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 786EC3858C98
Date: Tue, 29 Oct 2024 16:47:40 +0100
To: cygwin AT cygwin DOT com
Subject: Re: [Ms-nfs41-client-devel] Windows Server NFS, getfact not working
 on NFS
Message-ID: <ZyEDnPdkM0qiaXop@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CANH4o6NU5w055spGMtCDipzsmHRON7X6F5eOJCdu8oSd1xD7Gg AT mail DOT gmail DOT com>
 <CALXu0UcaTqWFYK_YpnAT1jxGcMqOs0jLE+hRAV_n_-dRxRF6vw AT mail DOT gmail DOT com>
 <CANH4o6PyJ5jiryGAb8A1n4SfP6sPVKUWEde2e97SHsyKG7-FzQ AT mail DOT gmail DOT com>
 <ZyDzSuUxrOLfCWPN AT calimero DOT vinschen DOT de>
 <d47bc2f0-6188-4b1c-84ce-f1d72106c330 AT gmx DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d47bc2f0-6188-4b1c-84ce-f1d72106c330@gmx.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Oct 29 15:08, Sam Edge via Cygwin wrote:
> On 29/10/2024 14:38, Corinna Vinschen via Cygwin wrote:
> > On Oct 29 13:56, Martin Wege via Cygwin wrote:
> > > No, FILE_PERSISTENT_ACLS is not in that output.
> > > 
> > > Reading https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa
> > > it means that the Windows NFSv4.1 server does not support ACLs?
> > 
> > https://learn.microsoft.com/en-us/answers/questions/1132611/windows-nfs-server-acls
> > 
> To the point as always. :-)
> 
> However the answer in that link raises more questions.
> 
> a) Does that mean NFS-served ACLs /are/ supported by Cygwin if the "stored
> in GPFS as POSIX ACLs" caveat applies?

If the external GPFS filesystem sets the FILE_PERSISTENT_ACLS flag when
communicating with a Windows client, then yes.  Otherwise no.

> I've just been reviewing the Cygwin user guide. The following took my eye.
> 
> > noacl - Cygwin ignores filesystem ACLs and only fakes a subset of
> > permission bits based on the DOS readonly attribute. This
> > behaviour is the default on FAT and FAT32. The flag is
> > ignored on NFS filesystems.
> 
> b) Does this mean ACLs are ALWAYS support on NFS or NEVER supported?

The user guide contains this:

https://cygwin.com/cygwin-ug-net/using-filemodes.html

NFSv3 == POSIX file permission bits as in st_mode.

As I wrote months ago, the NFSv4 driver should not use "NFS" as
filesystem name, but something like "NFS4". This way, the two
filesystems can be distinguished and handled separately.  Given that
Windows doesn't care for the name, but Cygwin does, this opens up the
chance to add special handling for the NFSv4 driver to Cygwin.

The first and foremost effect, without *any* changes in Cygwin
necessary, would be that Cygwin handles the NFSv4 driver just like
any other non-NFS driver:

- Flags like FILE_PERSISTENT_ACLS would actually be utilized.

- stat info would be fetched using
  NtQueryInformationFile(FileAllInformation) rather than via the
  NFS-specific NtQueryEaFile("NfsV3Attributes").

- Along the same lines, symlinks won't be recognized by the
  NfsV3Attributes stat info, but by the Windows default way
  of checking for a reparse point of type IO_REPARSE_TAG_SYMLINK
  (or IO_REPARSE_TAG_LX_SYMLINK if NFSv4 supports it).

And repeating myself, maybe in other words, but Cygwin doesn't do
anything magical.  It's just a user-space DLL relying on the same info
the Windows OS gets.  It's just a matter of how to use that info.

So if you get the info through to Windows, there's always a way to get
it through to Cygwin either.  


Corinna

-- 
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