New subject: [Bug 59729] Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID

May 6, 2026

      http://bugs.winehq.org/show_bug.cgi?id=59729

            Bug ID: 59729
           Summary: Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID
           Product: Wine
           Version: 11.8
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: mountmgr.sys
          Assignee: wine-bugs@list.winehq.org
          Reporter: joel@airwebreathe.org.uk
      Distribution: ---

Created attachment 80883
  --> http://bugs.winehq.org/attachment.cgi?id=80883
reproducer.c

(AI-assisted report)

Wine's `FileFsAttributeInformation` handler does not include the
`FILE_SUPPORTS_OPEN_BY_FILE_ID` flag (`0x01000000`) in the filesystem
attribute flags for volumes reported as NTFS.

On real Windows (NTFS), `GetVolumeInformationW()` /
`GetVolumeInformationByHandleW()` returns this flag. It has been
present on NTFS since Windows Vista.

## Impact on MSYS2

The MSYS2/Cygwin runtime checks the filesystem flags at mount time to
decide whether to enable POSIX rename semantics. The relevant Cygwin
code path is:

1. `mount_info::init_usr_pathconv()` queries `FileFsAttributeInformation`
   for each mount point.
2. The flags are stored in `fs_info::flags_`.
3. When `rename()` is called, Cygwin checks whether to use
   `FileRenameInformationEx` with `FILE_RENAME_POSIX_SEMANTICS`.
4. The decision requires **all three** conditions:
   - `wincap.has_posix_rename_semantics()` is true (Windows 10 1709+)
   - The filesystem type is NTFS
   - The filesystem flags include `FILE_SUPPORTS_OPEN_BY_FILE_ID`

Without `FILE_SUPPORTS_OPEN_BY_FILE_ID`, Cygwin falls back to legacy
rename behavior using `FileRenameInformation` (info class 10) with
only `FILE_RENAME_REPLACE_IF_EXISTS`. This legacy path returns
`STATUS_ACCESS_DENIED` when the destination file is held open by
another process, even if the handle was opened with
`FILE_SHARE_DELETE`.

This directly causes the `pacman-key --populate` failure documented in
the `posix-rename-semantics` bug: GnuPG's `rename(pubring.gpg,
pubring.gpg~)` fails because `gpg-agent` holds `pubring.gpg~` open
from the previous signing operation.

**Note:** Even with `FILE_RENAME_POSIX_SEMANTICS` support implemented
in the Wine server (see the `posix-rename-semantics` bug), MSYS2 will
never use it unless this flag is also reported, because the Cygwin
runtime gates the feature on the filesystem attribute check.

## Reproducer

```
x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c
wine reproducer.exe
```

### Expected output (Windows 10+, NTFS)

```
C:\: fs=NTFS flags=0x03e706ff
C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS)
Z:\: fs=NTFS flags=0x03e706ff
Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS)

PASS
```

(Exact flag values vary by Windows version and filesystem features.)

### Actual output (Wine 10.0)

```
C:\: fs=NTFS flags=0x0000000a
C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: NO (FAIL)
Z:\: fs=NTFS flags=0x0000000a
Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: NO (FAIL)

FAIL
```

## Analysis

Wine reports NTFS filesystem attributes in two locations:

### `dlls/ntdll/unix/file.c` — `NtQueryVolumeInformationFile`

The `FileFsAttributeInformation` handler's default (NTFS) case returns:

```c
info->FileSystemAttributes = FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS;
```

This is `0x00000002 | 0x00000008` = `0x0000000a`.

### `dlls/mountmgr.sys/device.c` — `harddisk_query_volume`

The `FileFsAttributeInformation` handler's default (NTFS) case returns:

```c
info->FileSystemAttributes = FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS
                              | FILE_SUPPORTS_REPARSE_POINTS;
```

This is `0x00000002 | 0x00000008 | 0x00000080` = `0x0000008a`.

Neither includes `FILE_SUPPORTS_OPEN_BY_FILE_ID` (`0x01000000`).

Real Windows 10 NTFS reports a rich set of flags including at minimum:
`FILE_CASE_PRESERVED_NAMES`, `FILE_PERSISTENT_ACLS`,
`FILE_SUPPORTS_REPARSE_POINTS`, `FILE_SUPPORTS_OPEN_BY_FILE_ID`, and
many others. The minimal fix is to add `FILE_SUPPORTS_OPEN_BY_FILE_ID`
to both default NTFS cases.

## Fix

The fix is straightforward — add `FILE_SUPPORTS_OPEN_BY_FILE_ID` to
the NTFS default filesystem flags in both locations:

- `dlls/ntdll/unix/file.c`: `NtQueryVolumeInformationFile`,
  `FileFsAttributeInformation` default case
- `dlls/mountmgr.sys/device.c`: `harddisk_query_volume`,
  `FileFsAttributeInformation` default case

The constant is already defined in `include/winnt.h`.

Commit on branch `msys2-hacks-23`:

- `578e06f7b57` `ntdll, mountmgr: Report FILE_SUPPORTS_OPEN_BY_FILE_ID for NTFS
volumes.`

### After fix

```
C:\: fs=NTFS flags=0x0100008a
C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS)
Z:\: fs=NTFS flags=0x0100000a
Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS)

PASS
```

## Verified against

- Wine 10.0 (nixpkgs upstream): **bug present** (`flags=0x0000000a`)
- Wine 11.4 (msys2-hacks-23, commit `578e06f7b57`): **fixed**
(`flags=0x0100000a`)
- Real Windows 10 build 22631: flag present (`flags=0x03e706ff`)

## Environment

- Wine: 10.0 (nixpkgs), 11.4 (msys2-hacks-23)
- Windows: 10.0.22631 (reference)
- MSYS2 runtime: 3.6.9-1
- Host: Linux x86_64 (NixOS)

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 59729] New: Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)