find.exe -ls reports owner as "archive", does not report owner_group (GROUP_SECURITY_INFORMATION)

[aureliencouderc]

find.exe -ls reports owner as "archive", does not report owner_group:

$ find.exe . -ls
0 4 archive 0 0 0 9 Jun 5 09:32 .
0 2048 archive 0 0 0 2097168 Jun 5 09:30 .\xxx
0 4 archive 0 0 0 0 Jun 5 09:14 .\myfile

Cygwin 3.6.9 on French Windows 11 reports this:
$ find . -ls
1487791 9 drwxr-xr-x 2 aucou Aucun 9 Jun 5 11:32 .
1487906 17 -rwxr-xr-x 1 aucou Aucun 2097168 Jun 5 11:30 ./xxx
1487792 1 -rw-r--r-- 1 aucou Aucun 0 Jun 5 11:14 ./myfile

It is important to get the Windows GROUP_SECURITY_INFORMATION" (group identity) in this case.
Please read https://learn.microsoft.com/en-us/windows/win32/secauthz/security-information

[caomengxuan666]

I checked the code. The issue is in deps/findutils/src/find/matchers/ls.rs. On Windows, format_permissions() reads file_attributes (which includes FILE_ATTRIBUTE_ARCHIVE = 0x0020) and outputs "archive" as the permission string. And user and group are hardcoded to 0 — no GetSecurityInfo() / LookupAccountSid() calls.

So what looks like "archive" in the owner field is actually the permission field being filled with file attributes, while the real owner and group fields are just zeros.

Fix would need:

1. GetSecurityInfo() to get owner SID and group SID
2. LookupAccountSid() to convert them to names
3. A proper format_permissions for Windows (maybe d|rwx style or just leave it)

Hmmmm,I would check more seriously and open a pr to resolve it.

[caomengxuan666]

I opened an upstream findutils PR for this: uutils/findutils#706

It changes the Windows find -ls path to print a POSIX-like permission string instead of raw file attributes, and resolves owner/group via GetNamedSecurityInfoW + LookupAccountSidW. Once that lands upstream, this repo can update the deps/findutils submodule pointer.