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.]
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
