Build Runner: Initial Implementation for File System Watching on Windows

[jayrod246]

Closes#20598.

This initial implementation has the limit of 64 directories due to the usage of WaitForMultipleObjects. If merged, a follow up issue should be created to track overcoming that limitation.

Using IO completion ports instead of WaitForMultipleObjects, I am able to observe more than 64 directories at once.

BTW First time contributing, not very experienced with contributing on GitHub in general, but I love Zig. And I saw this issue and thought it would be a good learning opportunity for me.

[jayrod246]

windows.kernel32.ReadDirectoryChangesW is recently removed in #19641

Thoughts on where or how I can reintroduce it? Or if there is an Nt way it can be replicated?

[squeek502]

Re-adding kernel32.ReadDirectoryChangesW seems fine for now IMO. The Nt implementation can be figured out later (FWIW it looks like the relevant ntdll function is NtNotifyChangeDirectoryFileEx)

[jayrod246]

I added an error return to readChanges and some accountability for resources.

I still need to deal with this point though:

Note, though, that it also may be true that the dh_gop.found_existing case is impossible. Opening the same directory twice does not result in the same HANDLE:

conststd=@import("std");
pubfnmain() !void {
vardir1=trystd.fs.cwd().openDir(".", .{});
deferdir1.close();
vardir2=trystd.fs.cwd().openDir(".", .{});
deferdir2.close();
std.debug.print("1: {}\n2: {}\n", .{ dir1.fd, dir2.fd });
}

results in

1: anyopaque@9c
2: anyopaque@98

[jayrod246]

Instead of keying on the file handle itself, which is determined to be different each NtCreateFile call, would it be best to key on a FILE_ID_INFORMATION structure returned by NtQueryInformationFile? I believe that it is unique per file and volume. If it already exists, I would just close that handle and keep the existing one open.

edit: Further reading I found that FileId is not supported on Fat32. To determine that, you check if the FileId is zero and if so, the file system doesn’t support it. So, I could hash on the VolumeSerialNumber and, the FileId when non-zero, or a number based on I’m guessing an all lowercase full path?

[squeek502]

I think the way to go might be:

• Open a handle to the dir as you are currently
• Call NtQueryInformationFile with FILE_INTERNAL_INFORMATION to get the IndexNumber
• Call NtQueryVolumeInformationFile with FILE_FS_VOLUME_INFORMATION to get the VolumeSerialNumber

Then hash the combination of those.

Some examples of calling NtQueryInformationFile/NtQueryVolumeInformationFile can be found here:

• zig/lib/std/fs/File.zig

  Lines 211 to 217 in ff02bf4

  	vario_status: windows.IO_STATUS_BLOCK=undefined;
  	vardevice_info: windows.FILE_FS_DEVICE_INFORMATION=undefined;
  	constrc=windows.ntdll.NtQueryVolumeInformationFile(handle, &io_status, &device_info, @sizeOf(windows.FILE_FS_DEVICE_INFORMATION), .FileFsDeviceInformation);
  	switch (rc) {
  	.SUCCESS=> {},
  	else=>returnfalse,
  	}

• zig/lib/std/fs/File.zig

  Lines 457 to 469 in ff02bf4

  	vario_status_block: windows.IO_STATUS_BLOCK=undefined;
  	varinfo: windows.FILE_ALL_INFORMATION=undefined;
  	constrc=windows.ntdll.NtQueryInformationFile(self.handle, &io_status_block, &info, @sizeOf(windows.FILE_ALL_INFORMATION), .FileAllInformation);
  	switch (rc) {
  	.SUCCESS=> {},
  	// Buffer overflow here indicates that there is more information available than was able to be stored in the buffer
  	// size provided. This is treated as success because the type of variable-length information that this would be relevant for
  	// (name, volume name, etc) we don't care about.
  	.BUFFER_OVERFLOW=> {},
  	.INVALID_PARAMETER=>unreachable,
  	.ACCESS_DENIED=>returnerror.AccessDenied,
  	else=>returnwindows.unexpectedStatus(rc),
  	}

(I'd recommend using that BUFFER_OVERFLOW handling for the NtQueryVolumeInformationFile since we don't care about the volume name)

[jayrod246]

Forgot that I had to add FILE_FS_VOLUME_INFORMATION in windows.zig, will fix later today.

[squeek502]

Looking good IMO, nice work!

Seems to be working as expected from my testing. Tested on NTFS, FAT32, and a networked Samba share and they all worked fine.

[andrewrk]

Nice work!