On 29/10/2024 15:47, Corinna Vinschen via Cygwin wrote:
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-aclsTo 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
Hi. My apologies if I've annoyed you. It was certainly not my intention.I understand that Cygwin can only use the underlying APIs made available to it and I'm not trying to suggest that anything should or should not be supported either now or in the future. I also appreciate that NFSv4 has ACLs baked in whereas they are (sometimes) bolted on using OOB RPC in earlier iterations of NFS, same as file locking I believe.
But boil it back down to Martin's original question.If he can see/use ACLs when mounting an NFS share from a Windows server using a Linux client, should it be /possible/ for him to do so for the same share from a Cygwin+SFU+Windows client?
Can anyone give him a definitive answer? A simple yes or no at this point? If 'yes', given he claims he's getting 'no', what might be blocking him? I have no stake in this. I don't use Windows NFS servers. -- Sam Edge
OpenPGP_0x8AC2CEBF54528E30.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 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
