Hi all,
Is there any special reason that most of my drives are shown twice in
/proc/partitions on my home machine?
(it's still Windows 7)
Notably, all drives in between the first (C:) and the last (S:).
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 50010760
onnectors (drive C: is one of them, BTW). Drive S: is a
multi-purpose
card reader, which is actually a USB-interfaced removable device (so it's
different from
other drives).
> $ df -a
$ df -a
Filesystem 1K-blocks Used Available Use% Mounted o
-29 08:42 UTC
> getent passwd $USER
NCBI_NT+User(1606)@NCBIPC9135 /cygdrive/c/WINDOWS/system32
$ getent passwd lavr
lavr:*:1050182:1049089:U-NCBI_NT\lavr,S-1-5-21-2137354491-1741569864-122644288-1606:/home/lavr:/bin/bash
There's no stray /etc/passwd that might have gotten in the way, either:
> Unless of course you execute bash with -noprofile.
The only way I can start bash now, is from cmd.exe, since terminal (mintty) is
not working for me,
as I explained in my first message:
C:\WINDOWS\system32>c:\cygwin64\bin\bash
NCBI_NT+User(1606)@NCBIPC9135 /cygdrive/c/WINDOWS/system3
More info:
Running "cygcheck -rvs" from under bash (that I could only start from cmd.exe
as shown earlier)
does not seem to show anything unusual (I have only single install of Cygwin,
there's no conflict
of any kind, and all the packages check out Okay).
SysDir: C:\WINDOWS\sys
> -Original Message-
> From: Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> Sent: Monday, August 02, 2021 10:03 AM
> To: cygwin@cygwin.com
> Subject: RE: Seeing double in /proc/partitions (Win 7 Home)
>
> > If you don't have it already, download the winobj tool from
&
> Just paste it into your mail text.
I posted links to the screenshot images on my G-drive... I can't post them
into text as they are graphical
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Doc
XYZ12),1085362(XYZ13
XYZ14),1055672(XYZ15),1055702(XYZ16),1053394(XYZ17),1055703(XYZ18),70145(XYZ19
XYZ20 XYZ21 XYZ22),1083944(XYZ23),401408(XYZ24 XYZ25 XYZ26)
The corresponding id.strace file (the command was "C:\Cygwin64\bin>strace -m
all -n -o id.strace id > id.out") is below.
No
> Did you reboot your system since password change? I mean proper reboot, not
It was properly rebooted with "shutdown /r"
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https
> Is NCBI_NT the primary domain of the machine as well? I. e., is the machine
> in the same domain as your user account?
Yes, AFAIK. Is it the both the primary domain of the host and my account.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.ht
> > Did you reboot your system since password change? I mean proper reboot, not
>
> It was properly rebooted with "shutdown /r"
>
But TBH, I did this out of lack of anything else: I don't think a reboot
should be necessary when a password
is changing. Nothing else on the machine was required t
> Oops. Running cygserver is counter-productive in this case. The actual
> fetching of user and group data will then occur inside cygserver and
> nothing of import will show up in the trace output.
Hmmm.. I'll see what I can do (because it's run with admin privs, which I
don't have -- have to
it very clean.
Interesting observation, though, that I just ran "strace cat /proc/partitions",
and the output did not contain anything doubled:
major minor #blocks name win-mounts
8 0 500107608 sda
8 1102400 sda1
8 2 488280064 sda2 C:\
816 10
da
8 1 102400 sda1
8 2 488280064 sda2 C: 8 16 1000204632 sdb
8 17 1000202240 sdb1 D: 8 16 1000204632 sdb
8 17 1000202240 sdb1 D: 8 32 1000204632 sdc
8 33 1000202240 sdc1 G: 8 32 1000204632 sdc
8 33 1000202240 sdc1 G: 8 48 1000204632 sdd
8 49 1000202240 sdd1 I: 8 48 1000204632 sdd
8 49 1000202240 sdd1
> Also this is kinda unexpected:
Sorry, scratch that, the backslash in the pay with the shell... So explains the
weirdness
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:htt
/Device/Harddisk5/Partition1 ->
/proc/sys/Device/HarddiskVolume59
And, Oh!, from the same elevated admin shell, I get no doubles from "cat
/proc/partitions", either!
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 500107608 sda
8 1102400 sda1
at I used to start from "cmd.exe" (when the terminal
wouldn't open up):
C:\Windows\System32>cd \cygwin64\bin
C:\Cygwin64\bin>bash
lavr@NCBIPC9135 /usr/bin
$ id
uid=1050182(lavr) gid=1049089(Domain Users) groups=1049089(Domain
Users),555(Remote Desktop Users),545(Users),559(Pe
> All Cygwin services need to be shut down prior to running Cygwin Setup
Huh? Where Cygwin Setup is coming from? I don't understand what you are
talking about.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cyg
> I asked this in case something like cygserver was running, or that your user
> SID had changed in the meantime (f.e. due to domain migration).
> That would actually require a proper reboot.
No domain migration, just a password change. It was properly rebooted,
nonetheless.
Anton Lavrentiev
Co
> How do you install and upgrade Cygwin and Packages?
Why? I wasn't upgrading anything this time. But when I need to upgrade, I
create a ticket for admins to stop cygserver,
then I update all the files, and then I create a ticket to restart the service.
(BTW, Setup won't be able to complete
a
were reported
while
I was locked out of my Cygwin terminal (and cygserver running), with that they
are
reported now, when everything appears to work correctly (and cygserver is
stopped).
Cygcheck.exe: with cygserver running (note missing closing parentheses for
numeric +User and +Group,
and some gar
> You were "upgrading" your domain account AD data cached by cygserver.
I restarted my PC at some point with "shutdown /r" -- I have no idea how
cygserver can preserve its caching across this. It's not a "fast restart".
The system restart did not help.
I'd really appreciate if you could _read_
> "during user-initiated shutdowns, the kernel, drivers, and services are
> preserved and restored, not just restarted."
Which was why I specifically used "shutdown /r", which is:
/r Full shutdown and restart the computer.
We've been advised by our admins that this command does a tru
Hi all,
I have a question that might have been asked on here before, but I wasn't able
to find it, so here it goes:
In Cygwin, it seems like for the local native file system (NTFS), file inode
numbers (struct stat::st_ino)
get generated by hashing the file names, rather than them being tied to
Replying to myself:
> So the question: was there any reason that the native NTFS file IDs (which
> are quite
> reasonable) weren't used
Sorry for posting my previous question, it looks like the inode numbers are
actually NTFS file IDs for the files.
They are reasonably looking when in hex, but
> 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,
pshots that follow).
Winobj (runs elevated to be able to open those entries) reports all drives
without any duplication.
And so does diskpart.
Also, looks like C: is always shown correctly in /proc/partitions: with the
correct number
of partitions, and without any repetitions.
Right now,
s
8 0 500107608 sda
8 1102400 sda1
8 2 488280064 sda2C:\
816 1000204632 sdb
817 1000202240 sdb1D:\
832 1000204632 sdc
833 1000202240 sdc1G:\
848 1000204632 sdd
849 1000202240 sdd1I:\
864 1000204632 s
> 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);
>
>
> 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
> 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
> 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
bytes_read = 34346, context = 461, status = 0x
major minor #blocks name win-mounts
8 0 500107608 sda (461, Harddisk0)
8 1102400 sda1
8 2 488280064 sda2C:\
816 1000204632 sdb (461, Harddisk1)
817 1000202240 sdb1D:\
832 1000204632
8 1102400 sda1
8 2 488280064 sda2 C:\
816 1000204632 sdb
817 1000202240 sdb1 D:\
832 1000204632 sdc
833 1000202240 sdc1 G:\
848 1000204632 sdd
849 1000202240 sdd1 I:\
864 234431064 sde
865 234428416 sde1 F:\
Hi,
Please consider the following Cygwin session:
$ cd ~
$ pwd
/home/user
$ touch file
$ ls file
file
$ cygpath -w ~
C:\cygwin64\home\user
$ mkdir /cygdrive/g/cygwin/dir
$ ln -s /cygdrive/g/cygwin/dir ./dir
$ ls -l dir
... dir -> /cygdrive/g/cygwin/dir/
$ cd dir
$ pwd
/home/user/dir
$ cygpath
initializing every
> member
> after Corinna's last patch.
>
Well, if one day MS decides to use some of the Reserved field by splinting off
a new
named field out of that bulk of bits, the code will be in trouble again...
While with memset, bzero or C-style initializer, everything is g
> Renamed that DLL -- same behavior, and same access violation in WinDbg.
> Killed all Beyond Trust Services/Tasks -- same behavior.
Does WinDBG still show the DLL loaded?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: h
000800118088 r10=0001
r11=0003F4F45359 r12=B9E0 r13=FFFFB9E8
r14=0008000DE3D8 r15=0008000E7388
rbp=B9F8 rsp=B988
program=C:\cygwin64\bin\svn.exe, pid 51421, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame
> Subversion seems to have along list of upstream issues
>
> can you check if the issue was already noted and solved upstream ?
> If so I can deploy a new release.
Thanks for the suggestion!
Looks like 1.14.1 dated Feb 2021 is the latest official release, per their
website;
and that's what we h
> Click the Cygwin64 Terminal icon on the desktop, opens briefly then closes.
> Suggested troubleshooting steps?
Try to completely stop and then re-start Cygserver (found in "windows
services").
HTH,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problem
Keith,
There should be only one of them running, unless you have multiple Cygwin
installations,
then there can be per-installation instances. Restart of all Cygwin processes
was always
required (because the main DLL may not be properly replaced while it's in use by
any process) -- but a reboot
> for svc in cygserver $( cygrunsrv --list | grep -v cygserver ); do net start
> "$svc"; done
> and you're golden!
Not so fast, you must have admin rights to start any Windows services,
including cygserver.
So maybe just bronze, and not so golden
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
> Else how would you stop them in the first place?
Restarting the OS was the way (post install, to restart with the new DLL),
but that no longer works anymore with Win10.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: ht
>
> In my case the directory (where I renamed the file) is on my C-drive.
>
If the file is currently open for access, the move can turn out to be a copy,
actually.
Check open files to make sure whatever you are moving is not being opened /
accessed from any other program.
Anton L
> Please add some way of identifying that programs are running under Cygwin.
Have you tried to use the "uname" command for the identification purposes?
$ uname
CYGWIN_NT-6.1
$ uname
CYGWIN_NT-10.0
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.h
Hi all,
An empty PATH element (":xxx" or "xxx::xxx" or "xxx:") is to be considered as
the current directory (from the very first days of Unix).
However, Cygwin does not seem to obey the rule.
Consider the following simple C program:
$ cat hello.c
#include
#inc
t; Anton (NIH/NLM/NCBI) [C] via Cygwin
> Sent: Sunday, June 26, 2022 11:10 AM
> To: 'cygwin@cygwin.com'
> Subject: [EXTERNAL] Cygwin's execlp() does not work with an empty $PATH
> element
>
> Hi all,
>
> An empty PATH element (":xxx" or "xxx::
Hi,
It looks like if a file descriptor is inquired a few times in a poll() call
with different events (and for one of those events the file descriptor is
"ready"),
only that occurrence gets reported correctly, and all other occurrences get the
returned event just "copied over" (and thus, it may
(different drive "cd /cygdrive/g/cygwin" -- it's
NOT where Cygwin is installed,
just a folder that keeps files for Cygwin development, the installation is on
C:\Cygwin64), I cannot predict
the results. What's weird is that fstat and stat report different file modes.
$ pwd
/c
cal Home Directory
read only = No
hosts allow = [:snipped:]
acl allow execute always = True
HTH,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> From: Takashi Yano
> Sent: Friday, November 08, 2024 6:51 AM
> To: cygwin@cygwin.com
> Cc: Lavrent
> OpenSSH being "fatal: seteuid 4096: Function not implemented".
Do you have cygserver running as well?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com
> The error is valid because the addition of this very old C++ feature
> took a very long time :-)
Well, it may be so, but adding the parameter names in those prototype on Cygwin
end of things would be a better and less disruptive approach, IMO.
$.02,
Anton Lavrentiev
Contractor NIH/NL
> We could change this to a macro instead:
>
> -static inline void setproctitle_init (int, char *[], char *[]) {}
> +#define setproctitle_init(c, a, e)
Changing to the empty marco removes the side effects in the arguments (such as
len++, for example),
which may silently break e
> I'm agree with you, but on other *nix platforms, and even on Windows with
> winsock and AF_UNIX, connect() doesn't wait for accept(). I would like such
> behavior.
The behavior that connect() does not require accept() from the other end is
platform-specific.
It's your other system's courtesy, a
rk, because textmode
makes ordinary scripts fail. I have mounted my /cygdrive and /home
directories as textmode:
bash-3.1$ mount
C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type
system (binmo
de)
C:\cygwin\home on /home type system (textmode)
C:\cygwin\bin on /usr/bin type system
601 - 655 of 655 matches
Mail list logo
