Re: Duplicates in /proc/partitions

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug 18 18:36, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > And I just confirmed that if I print the context right before NtOpenFile(), and just do
> > the "continue",
> 
> But then I also tried this:  I removed the "continue" before "NtOpenFile()" and allowed it to proceed,
> but I moved NtClose(devhdl) right after the "printf" statement (that we were tweaking), and
> inserted the "continue" there, so it does not proceed with enumerating of the partitions.
> And so again, I got the output that matches my disks without the duplication.  So this actually
> exonerates NtOpenFile() :-)
> 
> $ ./proc_partition
> context = 282
> major minor  #blocks  name   win-mounts
> 
>     8     0 500107608 sda (282, Harddisk0, 144)
> context = 299
>     8    16 1000204632 sdb (299, Harddisk1, 144)
> context = 314
>     8    32 1000204632 sdc (314, Harddisk2, 144)
> context = 329
>     8    48 1000204632 sdd (329, Harddisk3, 144)
> context = 339
>     8    64 234431064 sde (339, Harddisk4, 144)
> context = 352
> DeviceIoControl (Harddisk5\Partition0, IOCTL_DISK_GET_PARTITION_INFO{_EX}) 5    8    80         0 sdf (352, Harddisk5, 144)

Unfortunately I can't reproduce the issue.  I created a couple of
virtual drives and added them to my W10 and my W7 VM, but to no avail.
The output always makes sense, e. g.,

$ ./proc_partition.exe
major minor  #blocks  name   win-mounts

    8     0  54525952 sda (169, Harddisk0)
    8     1    102400 sda1
    8     2  54420480 sda2    C:\
    8    16   1048576 sdb (181, Harddisk1)
    8    17   1045504 sdb1    E:\
    8    32   1048576 sdc (189, Harddisk2)
    8    33     32768 sdc1
    8    34   1013760 sdc2    H:\
    8    48   1048576 sdd (199, Harddisk3)
    8    49   1045504 sdd1    F:\
    8    64   1048576 sde (207, Harddisk4)
    8    65     32768 sde1
    8    66   1013760 sde2    G:\

The only interesting difference I can observe on Windows 7 is
that the offset changes quite often, compared to Windows 10.

I wonder if the Win32 API functions GetVolumeNameForVolumeMountPointW
or GetVolumePathNamesForVolumeNameW are the potiential culprit.

Can you apply the following patch, which disables the "win-mounts" output
and try again?

--- proc_partition.c.orig	2021-08-19 12:01:25.480105116 +0200
+++ proc_partition.c	2021-08-19 12:01:47.134099288 +0200
@@ -178,7 +178,7 @@ main ()
 	    swprintf (fpath, sizeof fpath,
 		      L"\\\\?\\GLOBALROOT\\Device\\%ls\\Partition%u\\",
 		      dbi->ObjectName.Buffer, part_num);
-	    if (GetVolumeNameForVolumeMountPointW (fpath, gpath, MAX_PATH)
+	    if (0 && GetVolumeNameForVolumeMountPointW (fpath, gpath, MAX_PATH)
 		&& GetVolumePathNamesForVolumeNameW (gpath, mp_buf,
 						     NT_MAX_PATH, &len))
 	      {


Thanks,
Corinna