Re: Duplicates in /proc/partitions

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2021-08-16 12:49, Corinna Vinschen via Cygwin wrote:
> On Aug 16 10:56, Brian Inglis wrote:
>> On 2021-08-16 08:51, Corinna Vinschen via Cygwin wrote:
>>> On Aug 13 12:56, David Balažic via Cygwin wrote:
>>>> [...]
>>>> $ cat /proc/partitions
>>>> major minor  #blocks  name   win-mounts
>>>>
>>>>       8     0 1000204632 sda
>>>>       8     1    102400 sda1
>>>>       8     2     16384 sda2
>>>>       8     3 999571820 sda3   C:\
>>>>       8     4    510976 sda4
>>>>       8    16  62522712 sdb
>>>>       8    17   4096000 sdb1   D:\
>>>>       8    18  58424664 sdb2
>>>>       8    16  62522712 sdb
>>>>       8    17   4096000 sdb1   D:\
>>>>       8    18  58424664 sdb2   E:\
>>>> [...]
>>>> So the second listing shows sdb twice. Also E: does not seem to exist
>>>> (see below).
>>>
>>> So, second report.  Which OS is that on?  I don't have any physical
>>> Windows machine anymore, so I have a bit of a problem to reproduce this.
>>>
>>> As I wrote in https://cygwin.com/pipermail/cygwin/2021-August/249012.html,
>>> I don't see how Cygwin would be able to duplicate entries, unless the OS
>>> itself duplicates entries.
>>>
>>> Somebody who can duplicate this issue would have to single step through
>>> function format_proc_partitions, see
>>>
>>> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_proc.cc;h=66d19ab82f;hb=HEAD#l1686
>>>
>>> and check what actually happens in the above cases.
>>
>> Could those with the symptoms not provide useful information using a script
>> run in an elevated admin shell listing the relevant contents of Windows
>> objects accessed by format_proc_partitions from /proc/sys/ similar to the
>> attached script and log from my system, where the correspondence is obvious?
> 
> Not sure if that helps, but it's worth a try.
> 
> Other than that, I created a standalone application, shamelessly copying
> the code from Cygwin's function format_proc_partitions() and tweaked it
> to drop Cygwin internals.
> 
> The core of the function doesn't actually need Cygwin internals. It's
> basically a double loop calling Windows functions and just using Cygwin
> internals to print out major and minor numbers and the device name.  The
> standalone application simply fakes those.
> 
> This allows any person who *can* reproduce the problem to run the code
> under a debugger like GDB and debug what's going wrong.
> 
> I attached the code to this mail.  Store it under the name "proc_partition.c".  Compile it in two different ways, first with optimization:
> 
> $ gcc -g -O2 -o proc_partition_O2 proc_partition.c -lntdll
> 
> Run it:
> 
> $ ./proc_partition_O2
> 
> If the output contains duplicates, take a note, but otherwise
> ignore it for now.
> 
> Next, build it without optimization for easier debugging:
> 
> $ gcc -g -o proc_partition proc_partition.c -lntdll
> 
> Run it:
> 
> $ ./proc_partition
> 
> If the output contains duplicates, great!  Now you can run it under
> GDB and step through and see where it goes awry.  If it doesn't, you'll
> have to debug the optimized version, which is sometimes a bit weird.
> I'd be really glad if this allows us to reproduce the issue.
> 
> If none of them reproduces the issue... uhm... anyway, let's try first.

Might be easier for users if they could just run a verbose diagnostic, 
that checks everything and dumps everything, maybe under strace, rather 
than navigate gcc and/or gdb.

Provide it like snapshots with sha512sum and sig?

[Even sysadmins would rather not deal with development tools if 
possible, and in many orgs, for audit, internal, and security controls, 
are prohibited from doing so, and that extends to many application 
support and usage roles, due to anti-fraud, audit, and security 
controls, originally directed towards org financial reporting, under 
regulations like US SOX, "EuroSOX" audit directives like 8th Company Law 
Directive on Statutory Audit (Directive 2006/43/EC), and national 
regulatory equivalents.]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]