.NET Win32设置只读未对齐，导致NTFS文件系统识别异常

在Windows平台上通过Win32 APIIOCTL_DISK_SET_DISK_ATTRIBUTES将磁盘设置为只读后出现了意料之外的行为磁盘属性面板显示已只读但NTFS文件系统仍允许写入或者反过来磁盘已取消只读但NTFS仍拒绝写入。这种磁盘层与文件系统层状态不一致的现象在iSCSI磁盘热插拔场景下尤为突出——同一LUN路径上先后挂载不同磁盘前一块盘的只读状态会残留给后一块盘。表面上看只读设置已经成功返回Get-Disk也确认为只读但实际写入操作却不受控制。问题的根源在于Windows磁盘架构的分层设计。Windows磁盘只读的两层架构与刷新机制Windows的磁盘只读实际上分为两层磁盘设备驱动层通过IOCTL_DISK_SET_DISK_ATTRIBUTES设置直接修改磁盘设备对象的属性。这一层是物理级的一旦设置成功所有对该磁盘设备的I/O请求都会被拦截。NTFS文件系统驱动层NTFS在内存中维护一个VCBVolume Control Block结构缓存了磁盘的只读状态。文件系统的读写判断依赖的是VCB中的缓存值而非实时去查询磁盘设备属性。关键问题在于NTFS不会主动轮询磁盘属性的变化。当通过Win32 IOCTL修改了磁盘只读属性后NTFS的VCB缓存仍然是旧值直到某种事件触发它重新加载。能触发NTFS重新加载磁盘属性的事件有四种触发方式作用层级副作用磁盘Offline/Online磁盘设备层卷会短暂不可用可能导致I/O错误卷Dismount/Mount文件系统层卷短暂不可用文件句柄失效FSCTL_LOCK_VOLUME / FSCTL_UNLOCK_VOLUME文件系统层短暂独占但影响最小PnP设备事件即插即用层不受控依赖硬件事件其中FSCTL_LOCK_VOLUME FSCTL_UNLOCK_VOLUME 是最轻量的方案。FSCTL_LOCK_VOLUME会强制NTFS刷新脏数据并获得独占访问权随后的FSCTL_UNLOCK_VOLUME释放锁时NTFS会重新从磁盘设备层读取最新属性并更新VCB缓存。这个过程不需要卸载卷也不需要脱机磁盘对业务的影响最小。这也就解释了为什么PowerShell Set-Disk -ReadOnly $true看起来总能正确生效——它底层调用的是WMI的MSFT_Disk.SetAttributes方法由storagewmi.dll实现内部大概率封装了Lock/Unlock或者等效的属性刷新逻辑。而直接调用Win32 IOCTL的开发者则需要自行处理这一层同步。解决方案Lock → SetReadOnly → Unlock基于上述原理正确的Win32只读设置流程应该是三步FSCTL_LOCK_VOLUME → 强制NTFS刷新脏数据获得独占访问↓IOCTL_DISK_SET_DISK_ATTRIBUTES → 设置磁盘只读属性↓FSCTL_UNLOCK_VOLUME → 释放锁NTFS重新加载最新属性到VCB对应的核心代码实现1 public static async TaskOperateResult SetReadOnlyAsync( 2 string volumeGuid, int diskNumber, bool isReadOnly, int timeoutSeconds 30) 3 { 4 // Step 1: Lock卷 — 触发NTFS刷新脏数据 获取独占访问 5 var lockResult await LockVolumeAsync(volumeGuid, timeoutSeconds); 6 if (!lockResult.IsResultOk || lockResult.Data IntPtr.Zero) 7 return OperateResult.ToError($Lock volume failed: {lockResult.Message}); 8 9 // Step 2: 设置只读 — 修改磁盘设备层属性 10 var setReadOnlyResult await Task.Run( 11 () SetReadOnly(diskNumber, isReadOnly) 12 ).TimeOutAsync(TimeSpan.FromSeconds(timeoutSeconds)); 13 14 if (!setReadOnlyResult.Success) 15 { 16 await UnlockVolumeAsync(lockResult.Data); 17 return setReadOnlyResult; 18 } 19 20 // Step 3: Unlock卷 — NTFS重新加载磁盘属性到VCB缓存 21 var unlockResult await UnlockVolumeAsync(lockResult.Data); 22 if (!unlockResult.Success) 23 return OperateResult.ToError( 24 $SetReadOnly ok but Unlock failed: {unlockResult.Message}); 25 26 return OperateResult.ToSuccess(); 27 }其中LockVolume通过卷GUID直接打开设备如\\?\Volume{xxx}调用FSCTL_LOCK_VOLUME。如果遇到ACCESS_DENIED (0x05)错误说明有其他进程持有该卷上的文件句柄需要加入重试逻辑建议5次重试间隔500ms1 public OperateResultIntPtr LockVolumeByGuid(string volumeGuid) 2 { 3 string devicePath volumeGuid.TrimEnd(\\); 4 IntPtr hVolume CreateFile(devicePath, 5 GENERIC_READ | GENERIC_WRITE, 6 FILE_SHARE_READ | FILE_SHARE_WRITE, 7 IntPtr.Zero, OPEN_EXISTING, 0, IntPtr.Zero); 8 9 if (hVolume INVALID_HANDLE_VALUE) 10 return OperateResultIntPtr.ToWin32Error(CreateFile failed); 11 12 if (DeviceIoControl(hVolume, FSCTL_LOCK_VOLUME, ...)) 13 return OperateResultIntPtr.ToSuccess(hVolume); 14 15 int err Marshal.GetLastWin32Error(); 16 CloseHandle(hVolume); 17 return OperateResultIntPtr.ToWin32Error($FSCTL_LOCK_VOLUME failed after, err); 18 }此外在磁盘挂载流程中操作顺序也很关键。应该在分配挂载点AddAccessPath之前完成只读设置因为一旦挂载路径暴露给系统第三方软件如杀毒、索引可能立即打开卷上的文件导致后续Lock失败。推荐的挂载操作顺序为取消只读 → 扩容 → 设置磁盘标签 → 设置只读 → 分配挂载点总结来说直接使用Win32 IOCTL操作磁盘只读时必须搭配FSCTL_LOCK_VOLUME/FSCTL_UNLOCK_VOLUME来同步NTFS文件系统的VCB缓存。这不是一个可选的优化而是一个必须的处理步骤——缺少它磁盘设备层和文件系统层的只读状态就会处于未对齐的状态导致写入行为与预期不符。