> 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
I had the issue at work and I asked my Systems team to configure the share
correctly on the Linux side of the things.
Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
The Z: drive is the "default share", and on whic
> /usr/bin/uptime always reports 0/0/0 average cpu load:
WJFFM
$ uptime
10:33:16 up 6 days, 14:06, 0 users, load average: 1.88, 2.04, 2.06
$ cat /proc/loadavg
1.88 2.04 2.06 2/5
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ:
> 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
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
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
> 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
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
> 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
> $ 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
> 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
> 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 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
> 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
> (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
> 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
> 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
Thank you for your prompt reply!
> TRIM is only enabled on a filesystem, if the underlying drive
> actually supports TRIM. The majority of SSDs support it, but not
> necessarily all SSDs.
>
> The above values, in particular SSINFO_FLAGS_NO_SEEK_PENALTY being
> FALSE, indicate that your drive is
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_SEEK_PENALTY
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 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
> :::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
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
> 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
> $ 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
> 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
> 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
> 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
> 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
> 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
> 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
> > 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
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, ""
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> > 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
> Sorry, the second gdb command should be
> info line *__assert+0x42a4
> > (Note the change in symbol name: two "_" there)
>
I think it'd be easier to "catch" the problem rather than to chase it by
running all commands under the debugger.
For that, define the CYGWIN environment variable (vi
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
> > 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
> I still think it's a bug in the code which requires some debugging effort
> on your side.
I think that OP does not understand that the page size constant is a property
of the platform, and not something that can be redefined at will even though
it's a macro.
> > #ifndef __CYGWIN__
> > #define
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
> 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,
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
> 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/msadox.dll
Both paths sho
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
> 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
> 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
> 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
> 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.
> 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
> 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
character by the OP's
terminal and, therefo
> 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
Hi all,
It took me awhile to figure this one out, but I think I have a good test case to
demonstrate a (rather serious, actually) issue with Cygwin sockets and
select/poll.
In short, when a reading end of a socket half closes for write (basically,
signaling the
other end of no more data to expe
> 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
> 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.
> 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
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
c
> 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
> 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
> 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
> 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
> 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
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
> 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
> 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
I forgot to mention that my "umask" is the standard 022...
The man page says that for directories with the ACLs, it is ignored.
So in my code bind() wouldn't have created the socket with 0777, and
that's fine! Which is why I call fchmod() to fix the permissions up,
and THAT does not work. BTW,
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
> 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
> 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
getfacl does not work even for the .socket "file" in my home directory for
which ~/sun works perfectly fine with permissions
(and all subdirectories crated with mkdir under it).
Also like I said, ~/sun also works perfectly fine in /cygdrive/g/cygwin/ but
not if I created a subdirectory with the
Hi all,
I am having an issue with socket file permissions...
So here's a mockup of code that shows the problem:
$ cat sun.c
#include
#include
#include
#include
#include
#include
#include
#define SOCKET "./.socket"
int main()
{
struct sockaddr_un addr;
struct stat st;
mode_t
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
ctory
$ unset PATH
$ echo $PATH
$ ./hello
Hello
Cygwin:
$ ./hello
exec: No such file or directory
$ unset PATH
$ echo $PATH
$ ./hello
exec: No such file or directory
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> From: Cygwin On Behalf Of
> Lavrentiev,
&g
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
#include
#include
#include
int ma
> 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
>
> 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 Lavrentiev
Con
> 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
> 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
--
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
> 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
> 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
Hi all,
Before I go ahead and try to submit this as a bug report with the Apache
Subversion project, I wanted to ask
if anybody experiences the same issue as me (or, maybe it's a Cygwin issue, not
svn's)...
I use svn at home on Cygwin via a tunneled connection to my SVN server at work,
so when
> 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
> >
> > With undocumented structure member initialization an issue, maybe better to
> > future proof using e.g.
> >
> > MEM_EXTENDED_PARAMETER mmap_ext = { 0 }; // or memset or bzero
>
> I don't see what this would accomplish. We're already initializing every
> member
> after Corinna's last
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 -w
> 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
> > 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..
> 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 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",
>
> $ 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
> 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
1 - 100 of 194 matches
Mail list logo
