size;
destbuf = (char *) crealloc_abort (destbuf, strlen (cmd) + 320);
return __small_sprintf (destbuf, "%d (%s) %c "
--- 1134,1144
stime = put.KernelTime.QuadPart * CLOCKS_PER_SEC / NS100PERSEC;
start_time = (put.CreateTime.QuadPart - stodi.BootTime.QuadPart)
I'm noticing that in a high-contention situation (many processes try to get
ahold of a semaphore) semget() on Cygwin starts to return EAGAIN (try again)
after about 62 processes has gotten to call semget() and are actively competing
for the semaphore (i.e. using the semaphore ID semget() returne
> The number of parallel open pipes, for instance. By default, 10
> worker threads handle the load and up to 62 processes can be handled
> in parallel.
Hmm, so it is not an OS-imposed restriction... Then I don't understand why it
wasn't made to "just work":
to create a thread per client until t
iority = pbi.BasePriority;
unsigned page_size = wincap.page_size ();
vmsize = vmc.PagefileUsage;
vmrss = vmc.WorkingSetSize / page_size;
vmmaxrss = ql.MaximumWorkingSetSize / page_size;
+ int nice = winprio_to_nice(GetPriorityClass(hProcess));
destbuf = (char *) crealloc_abo
> I pushed your patch with a short commit message.
Thanks! Thinking about that a little more, getpriority(PRIO_PROCESS) returns
the cached version of priority (since the last
setpriority()) but should return "live" version by re-getting and re-caching
the actual thing from the system:
1. The pr
Hi,
Here's the situation, I have a netmount "Z:" but I cannot make any files on it
executable from Cygwin:
$ mount
...
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
$ cd /cygdrive/z
$ pwd
/cygdrive/z
$ cat a.c
#include
int main()
{
printf("Hello world!\n");
return
> Following up on the original report of 3/10/2019.
Sorry to disappoint, but in no way it was an original report
https://cygwin.com/ml/cygwin/2018-07/msg00048.html
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http
Hi,
So nobody has any suggestions per this?
https://cygwin.com/ml/cygwin/2019-08/msg00126.html
TIA
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/
Thanks for responding!
> You need the "exec" mount option.
I thought so too, but how do I give that option to a drive that is "noumount".
I cannot dis- or re-mount it AFAICT.
$ mount
...
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
$ umount /cygdrive/z
umount: /cygdrive/z:
> What is your cygdrive mount options? Because default is, apparently,
> "binary,posix=0,user".
I have no idea where they are kept at, and how to change them.
Also, I couldn't make this work, anyways; yet I thought it should have worked:
> > $ mount -o exec //coredev2/home/lavr /mnt
> > $ mount
> If it's related to the ACL handling then it should start working when
> you remove the ACL on the file with 'setfacl -kb ...'
There are no special ACLs set on the file (that was just produced by GCC from
the source code, see my first email).
But I am now convinced that the problem is _entirely
> Have you checked the default ACL on the directory containing the file?
No, and there's nothing special there now that I checked. I can change the
"Read & Execute" for the .exe file from the Windows file properties
without having to deal with anything special or additional (like inherited
perm
x" on Linux side, then the
file becomes executable
from on Windows (from either within a Cygwin shell or outside).
AFAICT, there's nothing in strace (follows) rather than trying to get info on
"Z:" twice.
$ strace getfacl /cygdrive/z
--- Process 3412 created
--- Process 34
> Feel free to provide a patch, just, please, create a valid git commit message
"getpriority() consistent with process priority
https://cygwin.com/ml/cygwin/2019-08/msg00122.html";
The changeset is really trivial:
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index a914ae8.
> See the '+' at the end of the modes?
I saw that, and I also showed the "getfacl" output for that file and the
directory above, which showed
nothing additional.
> Maybe, but we'd still need to know how to get to the result you're seeing.
Just take a samba server (4.x) and mount a share with de
> You can often figure permissions problems
I already figured where the problem was, in how cygwin convers (or, actually
doesn't) the UNIX's "x" bit into
the native DAC for the underlying filesystem (to store as, again, "x" in the
Linux share). Missing that DAC, SMBD
returns "Access denied" for
xcept for the local disk C: (the only local drive my PC has):
$ mount
...
S: on /cygdrive/s type netapp (binary,posix=0,user,noumount,auto)
...
U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto)
...
Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
...
$ getfacl
> git format-patch output with commit message, please?
Please educate me how to do that; I am just using "git diff --no-color".
> The commit message should describe what the problem is and how the patch
> fixes it. One or
> two sentences are enough.
The commit message is there:
> > "getprior
Thanks for the hints!
> so...what's your umask?
It's 022. As far as it's concerned, umask should only be considered when
creating a new file, not to affect existing files' modes
(as with the chmod command). At any rate, the "x" bit in mine is unset, so
should not be having the issues what you
Hi,
When Cygwin generates a stacktrace (coredump) is it possible to get more than
16 frames printed out?
Looking at exceptions.cc, seems like not. Can it please be increased to 32,
for example?
Thanks,
Anton
--
Problem reports: http://cygwin.com/problems.html
FAQ: htt
Hi all,
I have the following stack trace (64 bit Cygwin app), and I can't figure how
the same frame RBP at 000C7B0 can be listed 3 consecutive times for various
functions (RIPs). Also if I follow the stack trace with gdb (and the trace is
all within Cygwin.dll based at 18004), it does
Hi all,
Here's a situation: I have a binary that was built (from a C source code) with
Cygwin 3.0.7 but "accidentally" used with much older Cygwin 2.11.2.
The binary won't actually launch. Instead, it most uneventfully (silently, no
crash - no drama) exits with an exit
ing that the
> binary required (obviously from the newer Cygwin ABI).
Running under strace gets a Windows error popup "thebadexecutable.exe - Entry
Point Not Found", that says inside:
---
The procedure entry point uname_x could not be located in the dynamic link
library
C:\Cygw
y with the shell's mkdir command.
> Can you give us more information about where that error is coming from? Are
> you
These are the relevant parts from strace (I think):
for "getfacl .socket" while in my $HOME:
62 25757 [main] getfacl 33904 symlink_info::check: 0x0 =
> Cygwin does not do this on a standard installation. Is it something you've
> done
I did use the standard Setup and nothing else... My $HOME looks fine, too:
$ cd
$ pwd
/home/ANTON
$ getfacl .
# file: .
# owner: ANTON
# group: None
user::rwx
group::---
other::---
default:user::rwx
default:gro
> That way I'm sure I won't have any surprises with permissions when working in
> /cygdrive/g/cygwin. Do you want to try that and see if it makes a difference?
I have no problems with /cygdrive/g/cygwin -- my socket file gets created there
with proper
permissions and reported so, too (both fstat
Looks like your program does not throw an exception on Cygwin (unlike it does
on Debian),
so it terminates normally, and the exit code 0 is not unexpected. Debian's
version
calls abort() and that sends a signal and terminates with a code 128+signal#,
and
SIGABRT=6, so 134 is the expected result
does not work. BTW, should I have called chmod() instead (which
is what the command line chmod does), the permissions would have been
set correctly on the socket file, but fchmod() would have misreported
them again (this time looks like a carryover from an earlier umask(0))!
$ diff sun1.c sun.c
3
> what your test program was actually doing. But you seem to be assuming that
> calling fchmod on a socket descriptor should affect the permissions on the
> socket file (assuming the socket is bound). Is that documented anywhere?
> POSIX
> says that the behavior of fchmod on a socket descriptor
> That's not what I'm seeing when I run your test program on Linux:
>
> $ ./sun
> fstat mode = 140666
> stat mode = 140777
True, but it creates the socket file with exactly how umask(0) told it to,
and stat() shows that. So yeah, I should retract that it works on Linux with
fchmod() -- on Linux
Hi,
There's some inconsistency between and :
sys/select.h has this:
---
/*
* Select uses bit masks of file descriptors in longs.
* These macros manipulate such bit fields (the filesystem macros use chars).
* FD_SETSIZE may be defined by the user, but the default here
* sh
> I'm no expert, but it seems the FD_SETSIZE should have been 128.
> Long is 8 bytes, 64 bits. One bit if one open file, 64 * 64 = 4096.
FD_SETSIZE is the file descriptor bitset capacity in _BITS_.
64 (as currently in there) means 1 int (on 64 bit platforms, or 2 ints on 32 bit
platforms, respect
> On Linux, select(2) is really only capable to
> handle file descriptors numbers up to descriptor number 1023,
That is not true. While FD_SETSIZE is defined as a fixed constant,
Linux kernel does not actually "know" (or care) about it.
So you can have an array of fd_sets, like this, in your cod
> Remember that 64 is MAXIMUM_WAIT_OBJECTS for WaitForMultipleObjects(),
> the underlying Win32 API used to implement select(), so using more than
> 64 hits some complex code to work around that...
True but the complex code (that involves thread spawning, if that's what you're
referring to)
will
> DESCRIPTION
>WARNING: select() can monitor only file descriptors numbers that are
>less than FD_SETSIZE (1024)-an unreasonably low limit for many modern
Whoever wrote this, was wrong (they might have never consulted the actual
kernel code, or were just
blindsided by FD_SETS
> However, discussing this shows how irrelevant the actual default value
> of FD_SETSIZE is.
Correct, yet the comments in the header files (along with used values) should
be consistent :-)
> [...] to define FD_SETSIZE according to its requirements anyway.
That'd work for CYGWIN right away; but
Hi all,
I need to do some deep debugging on Cygwin so I need to produce a core... And
it does not work.
So I reduced the problem to this minimal test case:
$ cat a.c
#include
int main()
{
abort();
}
$ gcc -Wall -g a.c
$ echo $CYGWIN
error_start=c:\cygwin64\bin\dumper.exe
$ ulimit -a
> Try using a more recent gdb. I just tried your test case with gdb-12.1-1
> (available as a test release), and it seemed to work.
Thanks for the quick response... Though I'd rather not use test releases.
The dumper binary and gdb in my case are supposed to be consistent with each
other
(insta
> The latest version of gdb that is not a test version is 11.2. But
> you are using 9.2.
I am using the older dumper as well, my working cygwin is not cutting edge.
$ dumper -V
dumper (cygwin) 3.2.0
What I am coming at is that if dumper is not consistent with gdb,
that does not make any sense.
> I've learned that once I get a setup that seems to be stable
That's what I thought about my 3.2.0 setup, too, but following your own
conclusions about the rolling release, one can never be sure...
Anyways, maybe it's time for me to upgrade. I did not because it looked
like 3.3 was coming out w
(what);
exit(1);
}
int main(int argc, const char* argv[])
{
struct sockaddr_in sin;
size_t total = 0;
int c = socket(AF_INET, SOCK_STREAM, 0);
if (c == -1)
error("socket");
memset(&sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_
> This was fixed in Cygwin 3.3.0, as the announcement of the latter stated:
Thanks! So maybe it is time to upgrade... after all LOL
> But you can still run a parallel Cygwin installation
I tried that before... And it did not work out well. Unless it's a VM,
there's a small but real chance tha
> I then see "C-@" echoed in the minibuffer, and the resulting *Help* buffer
> says
WFIW, in the DEC VT terminals (from where most of ANSI controls stem from),
Ctrl-Space used to
generate a NUL character (ASCII '\0'), and so maybe it is seen as a fill
characte
> Cygwin also generates NUL:
Thanks for checking! NULs were used as fill characters to throttle down the
line speeds, and were supposed to be ignored
in both hardware and software... I guess with the software terminal emulators
(such as MinTTY/Windows console/and such), that depends
on setting
> It seems that there's an exception: If no process has ever had the FIFO open
> for
> writing since it was opened for reading, then the FIFO is not considered to be
> at end-of-file.
IMO, when a virgin FIFO is read with a blocking read (of just one byte), it
will block -- it will not return 0.
> provided you run at least Windows 8.1
Why would that be a requirement?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: htt
> contains patches dropping W7 and W8 support:
Hmm... I understood that "dropping support" was not something that would
_require_ newer OS,
but that it may not work (or not guaranteed to work, patches not checked for
compatibility, etc)
on the older OSes... Are you saying that W7 and W8 would b
> for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8
> since the first 3.3.0 release in October 2021.
I saw that. It did not look alarming. It basically was like "you'll be on
your own".
> Supporting older OSes requires to keep workarounds in the code and
Understood. But you
Sorry for pressing this, I must be slow today.
> just won't run correctly anymore on W7/8
Won't or may not?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com
> Let's consider this problem again, but I don't see a quick and easy
> solution.
$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll<== IMO the problem is actually here
$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msa
corect.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> From: Cygwin On Behalf Of
> Lavrentiev,
> Anton (NIH/NLM/NCBI) [C] via Cygwin
> Sent: Monday, December 12, 2022 9:53 AM
> To: cygwin@cygwin.com; Frank Redeker
> Cc: Corinna Vinschen
> Subje
> The problem is that resolved paths may become longer than MAX_PATH.
Oh... But that'd be the same on any other OS that exceeds MAX_PATH, symlinking
is going to help work around that,
if the full path resolution was requested.
BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former,
Was supposed to be:
> symlinking is *NOT* going to help work around that
Sorry I am struggling with MS Outlook this morning
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:ht
fter all, it's Cygwin's quirks here.
>
> I still think it's a bug in the code which requires some debugging effort
> on your side.
>
> Having said that, if it's actually a Cygwin bug and you want it fixed,
> please provide a *simple*, self-contained testcase
> > returns 3 and sets errno to zero.
Note that "setting errno to zero" is not guaranteed in case of a successful
completion of a library function or a system call.
Generally, "errno" reflects an error that occurred last when such a call failed
(so in other words, in case of a successful
complet
Please pay close attention to how the command was shown to you, including the
use of the whitespace:
> >$ LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY
> In the terminal, when I use $LC_MONETARY = "en_ZM.utf-8" locale -ck
> LC_MONETARY
> Cygwin replies "-bash: LC_MONETARY: command not fou
, define the CYGWIN environment variable (via Windows) as:
error_start=c:\cygwin64\bin\dumper.exe
(that assumes that Cygwin is installed at c:\cygwin64)
Then whenever the abort occurs, you'll have a core file, which can be loaded
into GDB and the backtrace investigated.
Something like this:
$
> > You expect too much of ssh. ssh is a text utility, not an X one. The remote
> > vim
> > never sees your mouse actions: it's mintty that performs select / paste.
>
> Are you sure?
>
> man ssh:
>
> " -X Enables X11 forwarding. This can also be specified on a
> per-host basis in a co
> The Program is not throwing any error or success details. it simply comes
> out from the running screen without any error and success states.
127 is a POSIX return code meaning the binary file is not executable and cannot
be started.
Check what "ldd ./sample" shows. Most likely you are missin
> result should be
>
> r1 = 1, r2 = 1
>
And what was the result you saw?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: ht
> Should I be doing something differently? Or is it a bug?
It may be sort of a limitation (IIRC, in Cygwin's minires) but:
Did you try to use
options=osquery
and (separate by spaces) / or
options=inet6
in /etc/resolv.conf ?
HTH,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports
> It may be sort of a limitation (IIRC, in Cygwin's minires) but:
> > Should I be doing something differently? Or is it a bug?
> > the host and dig commands no longer work
Reading your question again, I don't think Cygwin's minires limitation (if any)
can be at play here because IIRC neither d
> Thanks. Unfortunately neither of those options fixes the problem.
Sorry... Did you try using the -d option to see what DNS servers these
commands try to actually connect to (and time out, eventually).
(strace can help as well, I think.)
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem
> FIFOs which don't make *any* sense
> ... FWIW, a remote NFS fileystem.
I got an impression that the OP is trying to deploy something (maybe the entire
Cygwin) onto an NFS share. So the named FIFO "file" is also created in there.
It's pointless to assume that the FIFO can be used as a communic
> What happens when the user executes two copies of an
> application /*such as PyCharm*/ on two separate machines sharing the same
> home directory? Does the directory entry and inode get reused on startup
> and/or deleted on exit? How does that impact the process instance on the
> other machin
> I don't have an answer to this problem yet.
>
> Can we use send(sock, "", 0) to reenable FD_WRITE, perhaps?
Can't it just be assumed that the socket is _always_ writeable _unless_ the
last send() failed?
In other words, try to always send() if it did not fail before. If it did,
only send() a
> it is not possible to diffentiate between Cygwin
> FIFOs and real FIFOs created from the remote side in `ls -l'
> output.
Why would that be necessary? If it's a FIFO, it can be used as a FIFO,
regardless where and how it was created..
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem rep
master.
>
> On Aug 25 14:23, Corinna Vinschen via Cygwin wrote:
> > On Aug 25 12:08, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > > > I don't have an answer to this problem yet.
> > > >
> > > > Can we use send(sock, ""
> > Can we use send(sock, "", 0) to reenable FD_WRITE, perhaps?
>
> Your idea seems to work. The following patch looks to solve the issue.
> Is it supposed to be any side effect()?
IMO you're triggering an undefined (or not well-defined) behavior, because of
the murky status
of the byte count of
> This thread is not about send() blocking or returning EAGAIN. This
> is about the behaviour of select(2) and poll(2).
I was merely commenting on your note that if select() returned a socket as
writable, and send() writes more than internally allowed, then send() would
block.
It wouldn't! It'd
> You don't seem to understand the problem.
I think I do, and that aligns with your explanation how Cygwin machinery works
to fake the FIFOs.
> If I can recognize a file as FIFO, I can use it as FIFO, regardless if it's a
> native FIFO or a Cygwin FIFO.
That's exactly what I meant!
> Show m
> You seems to reffer Linux man, however, this patch calls
I was referring to a known behavior. Your patch gets to call send(s,"",0),
which is technically a write call, and which in this case, falls into an
undefined
domain for its argument, and hence, may be expected to change without notice.
T
> For message-oriented sockets, a zero-length transport datagram is sent.
And how is that acceptable? This will interject a message into some
application protocol,
which may not be expected at the application level.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cy
> then use Windows Disk Management mmc app to identify
> the disk and convert from Disk n to /dev/sd[x], where Disk 0 is
> /dev/sda, Disk 1 is /dev/sdb, etc.
A much easier (and safer!) way to do that is to
$ cat /proc/partitions
-- it'll tell you exactly which /dev/sdX to use for the physical dr
> Does Cygwin (or Win32) have a function to convert "raw" ASCII IPv6 addresses
> into *.ipv6-
> literal.net per
If Windows API is documented to have such a function, you should be able find
it in the w32api package in Cygwin.
As for the "literal" representation, the only "standard" and document
> $ host -t ptr
I was talking about resolving the .ipv6-literal.net names via DNS.
Such as "fe80--219-99ff-feae-73ce.ipv6-literal.net"
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation
> What do you think that output is - the PTR is resolved to "localhost."
You obviously did not get the point that I was making. Using ip6.arpa *is* the
standard
way to get around with "DNS-like" IPv6 addresses, as it would be "understood".
Using
the "ipv6-literal.net" domain is not portable an
IMHO:
> 2. A different sequence
The word "different" in this context is ambiguous: is it "unrelated" as a
generator, or is it "not the same" sequence of the actual numbers?
> I read this as the newlib technique being one way of correctly implementing
> rand/srand, no?
If the first, then yes
> :::0:0:0/96 == :::0:a.b.c.d
https://www.ibm.com/docs/en/zos/2.1.0?topic=addresses-ipv4-mapped-ipv6
Mapped IPv4 addresses have the :::a.b.c.d short form, without any
intervening 0 word. The CIDR form above just denotes that 96 bits
are the prefix (the "network" part) and, thus, the
Hi All,
I was updating my Cygwin installation at home and that had accumulated some
"Unneeded" packages, which were very hard to deal with:
The default disposition is "Keep" (while logically, since they are "safe to be
removed", it should have been "Uninstall")
so it nearly got me a carpal synd
UPDATE:
Running "cygcheck -rvs" on the updated installation (after all the "Unneeded"
packages were gone),
revealed that a few packages had become "Incomplete":
base-files
libMagickCore6_6
libMagickCore7_9
perl
perl-mapages
squid
I re-ran Setup and chose these packages to "Reinstall" from the "
Hi Corinna,
I have a question about this tool getVolInfo that has recently "made the news".
Just updated my version to the latest and tried it on my drive C:, and
specifically this is what bugs me:
$ /usr/lib/csih/getVolInfo.exe .
...
SectorInfoFlags: 0x03
SSINFO_FLAGS_NO_SE
ast one (an older drive, indeed) report this:
TRIM Command: Supported (Indeterminate Read After TRIM)
But my C: drive (where Cygwin is installed) is a newer drive (one of those 4).
That's odd.
Also, the fact that I am unable to restore any files after deletion (all
contents become
0), just expe
> the process isn't allocated any CPU time until the timer expires.
Almost so. But the "sleep" functions are interruptible, so if a process (the
"sleep" command)
is somehow signaled, it will wake up prematurely, and will have to either put
itself back to
sleep (for the remaining unslept time) o
> Thanks for any hint
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files
HTH,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe in
> (I'm assuming it's too late by the time the /proc entry has been set up).
Actually, it's not. But beware, the suggested solution is absolutely NOT
portable:
These are the externals that /proc is referring to... (Not argc, argv passed
to main().)
extern char** __argv;
extern int
> Can you see what I'm doing wrong?
It used to work in the past, for sure, and was used in some code over here...
Since it was an ad-hoc thing, the behavior might have changed -- I haven't
checked it lately.
To make the full disclosure, we reassign the entire __argv here from the linear
memory
> It used to work in the past, for sure, and was used in some code over here...
And yes, like Corinna said, you have to use procps to actually see the changes.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwi
> that it matters at all, I'd like to +1 the suggestion/request of picking up
> support for
> setproctitle(3) in the next available release.
>> in which case I'd prefer to implement this via setproctitle(3), given
>> this API exists on BSD and Linux.
Well, I don't think setproctitle(3) exists on
> It's the same SID and it's your user SID. There can't be a group with
> the same name as a user account in the same user DB. Each account in
> the local domain or in an AD domain has to have a unique account name.
Exactly! Which is why we use "namegrp" (an established convention) for Windows
> $ host -6 google.com
> ;; connection timed out; no servers could be reached
FWIW, this hangs just the same on Linux when no IPv6 nameservers configured in
/etc/resolv.conf
What it tries to do is to inquire the nameserver at [::1]:53 (which is the
local host),
and then, since bind is not runni
> Maybe Cygwin should just ask Windows for the name servers?
Cygwin does ask Windows, by default, when gethostbyname() or getnameinfo() are
used (which most applications do).
The lookup does not depend on /etc/resolv.conf unless you configured it to do
so in "options" in there.
(That would be "o
Correction:
> (That would be "options osquery".)
Sorry, I have forgotten a few pieces since last time I worked with that code.
So in the absence of "/etc/resolv.conf", Cygwin uses OS (Windows DNS Query) API.
If /etc/resolv.conf is present, then "options osquery" tells Cygwin to use
the Windows
> A robust solution which also reduces syscalls does not necessarily
> require a precise answer here.
>
> I suggest writing a wrapper function which has on the stack
> CSTR sidbuf[SECURITY_MAX_SID_SIZE];
> and calls LookupAccountNameA() passing sidbuf as Sid.
> If it succeeds, then malloc() retu
Hi All,
I already tried to bring this up, but it looks like it was either ignored or
just slipped
through the cracks...
I have a few suggestions that IMHO would make Setup a teeny-bit user-friendlier.
Having to (re-)install Cygwin is probably the most dreaded action for
everybody, and
dealing
Thank you for your response about the shortcuts... And double-clicks (which
can be a ton when installing anew, as I figured).
> Doubleclick in "New" column toggles between "Skip" or "Keep" and the
> "preferred version". Ctrl+I selects the latter.and moves to the next row.
What if I don't need t
> Looking at /usr/include/w32api/minwinbase.h:
> snip
> typedef enum _FILE_INFO_BY_HANDLE_CLASS {
>FileBasicInfo /* is zero? */,
>FileStandardInfo,
>FileNameInfo,
>FileRenameInfo,
>FileDispositionInfo,
>FileAllocationInfo,
>FileEndOfFileInfo,
>FileStreamI
d up on being offered for download inadvertently.
Also, procmail fails to post-install (I don't need it, so I don't basically
care).
running: C:\cygwin64\bin\bash.exe --norc --noprofile
"/etc/postinstall/procmail.sh"
abnormal exit: exit code=1
Thanks,
Anton
--
Problem repor
ay, February 23, 2021 2:17 PM
To: Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Subject: Re: No admin setup questions
On Tue, 23 Feb 2021 at 16:08, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin
wrote:
> Also, I see a lot of messages in the cmd.exe "terminal" window, from where
> setup
tion on my work
PC (it's installed by me from under my
username).
Even rebooting the PC did not help to clear this up.
Weirdly enough, I can start bash from cmd.exe, but then it shows my username
numerically:
C:\WINDOWS\system32>c:\cygwin64\bin\bash.exe
NCBI_NT+User(1606)@NCBIPC9
501 - 600 of 655 matches
Mail list logo
