On Aug 19 15:46, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > Great! Looking forward to it.
>
> I'm happy to report that in the latest snapshot, the problem seems to be gone!
>
> $ uname -a
> CYGWIN_NT-6.1 X 3.3.0s(0.341/5/3) 2021-08-19 14:45 x86_64 Cygwin
>
> $ cat /proc/part
> Great! Looking forward to it.
I'm happy to report that in the latest snapshot, the problem seems to be gone!
$ uname -a
CYGWIN_NT-6.1 X 3.3.0s(0.341/5/3) 2021-08-19 14:45 x86_64 Cygwin
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 500107608 sda
8 1
On Aug 19 15:15, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > > loop is not working atomically. If a new object is inserted into the
> > > dir preceeding the currently handled entry (which, on a reliable system
> > > should *never* occur), the entry is moved by one, and the next
> >
> > loop is not working atomically. If a new object is inserted into the
> > dir preceeding the currently handled entry (which, on a reliable system
> > should *never* occur), the entry is moved by one, and the next
> > NtQueryDirectoryObject call returns the same object again.
Very interesting..
Hi Anton,
On Aug 19 13:26, Corinna Vinschen via Cygwin wrote:
> On Aug 19 12:03, Corinna Vinschen via Cygwin wrote:
> > 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
>
On Aug 19 12:03, Corinna Vinschen via Cygwin wrote:
> 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 th
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,
On Aug 18 18:18, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > printf ("%5d %5d %9llu sd%c (%lu, %ls)\n",
> > 8, (dev_name - 'a') * 16, size >> 10, dev_name,
> > (unsigned long) context, dbi->ObjectName.Buffer);
>
> I replaced with this instead (read_
> 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
tweak
> The directory handle is used (indirectly) in NtOpenFile() through the
> attributes, and
> I wonder if that call somehow distorts the internal position within the
> handle, and so
> it restarts from the wrong internal position in the outer loop.
And I just confirmed that if I print the context
> printf ("%5d %5d %9llu sd%c (%lu, %ls)\n",
> 8, (dev_name - 'a') * 16, size >> 10, dev_name,
> (unsigned long) context, dbi->ObjectName.Buffer);
I replaced with this instead (read_bytes added):
printf ("%5d %5d %9llu sd%c (%lu, %ls, %u)\n",
On Aug 18 14:18, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > On second thought, I have a vague idea... Could you please just add
> > something to the output, i.e, change lines 124/125 from
> >
> > printf ("%5d %5d %9llu sd%c\n",
> > 8, (dev_name - 'a') * 16, size >>
> On second thought, I have a vague idea... Could you please just add
> something to the output, i.e, change lines 124/125 from
>
> printf ("%5d %5d %9llu sd%c\n",
> 8, (dev_name - 'a') * 16, size >> 10, dev_name);
>
> to
>
> printf ("%5d %5d %9llu sd%c (%lu)\n",
>
On Aug 17 12:57, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > $ gcc -g -O2 -o proc_partition_O2 proc_partition.c -lntdll
>
> I ran the program (without gdb yet, can't doit right away)... Its
> output is a bit different from /proc/partitions (w.r.t. drive names),
Yes, it's just faked
> $ gcc -g -O2 -o proc_partition_O2 proc_partition.c -lntdll
I ran the program (without gdb yet, can't doit right away)... Its output is a
bit different from /proc/partitions (w.r.t. drive names), but I still see the
duplicates:
$ ./proc_partition
major minor #blocks name win-mounts
8
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 s
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 11
> Could those with the symptoms not provide useful information using a
> script run in an elevated admin shell listing the relevant contents of
Previously I reported that it worked for me correctly when elevated, and did
not work as an ordinary user.
I have to take this back (see the snapshots th
On 2021-08-16 08:51, Corinna Vinschen via Cygwin wrote:
On Aug 13 12:56, David Balažic via Cygwin wrote:
Before, during and after plugging in a n USB stick:
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 1000204632 sda
8 1102400 sda1
8 2 1
On Aug 13 12:56, David Balažic via Cygwin wrote:
> Before, during and after plugging in a n USB stick:
>
> $ cat /proc/partitions
> major minor #blocks name win-mounts
>
> 8 0 1000204632 sda
> 8 1102400 sda1
> 8 2 16384 sda2
> 8 3 999571820 sda3 C:\
>
> So the second listing shows sdb twice. Also E: does not seem to exist
Hi David,
I've seen double too, but was told that there's something off with my Windows
(7, Home), which I hardly believe is true... but anyways,
can you do the cat command from an elevated prompt, by any chance? On my box,
21 matches
Mail list logo
