> Looking at /usr/include/w32api/minwinbase.h:
> snip
> typedef enum _FILE_INFO_BY_HANDLE_CLASS {
>FileBasicInfo /* is zero? */,
>FileStandardInfo,
>FileNameInfo,
>FileRenameInfo,
>FileDispositionInfo,
>FileAllocationInfo,
>FileEndOfFileInfo,
>
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
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()
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
> $ 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
> 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
> 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:
> 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
> (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
> 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)
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
> :::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,
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
> 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
> $ 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/
> 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
> 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
> 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:
> 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.
> 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
> 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!
> > 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
gt; 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, "", 0) to reenable FD
> 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
> 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()
> 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
> 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
> 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
> 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
> 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:
> 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
> > 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
> 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
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
> > 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
> 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__
> >
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:
> 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
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:
> 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
> 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
> 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:
> 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
> 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,
> 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
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
> 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
> 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
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
> 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;
> 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
> 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
> 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,
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
*
> 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
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
> 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
> 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
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;
>However, use of this feature is deprecated, and POSIX
>notes that a conforming application shall use an explicit
>pathname (e.g., .) to specify the current working
>directory.
Since "SHALL" does not mean "MUST", I think this patch
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
$ 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,
> An
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
> 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:
>
> 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
> 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:
> 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:
> Great, thanks! I pushed all your resolver patches.
Thank you! I'll be submitting the last tiny little one in a sec :-)
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> Thanks for the description. Would you mind to recreate your patch with
> a matching commit message text explaining the debug flag setting?
Okay, just did.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> I pushed patches 1 and 3 to 5. I fixed the consitency typo
> throughout.
Thanks! (and oops :-)
> Right now, the debug flag gets set in several places throughout the
> code. Given you set the debug flag above, doesn't that mean several
> code snippets setting the debug flag later in the code
> 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
> It is reported by 'configure --help', at the appropriate level (although
> since enable is the default, I probably should have written
> '--disable-doc' here).
Can you please make it show as --disable-doc ?
Also, can you please make it visible in the top-level configure?
Thanks,
Anton
Hi Corinna,
> Other than that, the remaining patches look good, except, adding a short
> description what patch 7 does to the commit message would be great for
> later readers of the git log.
I resubmitted the patches with a little improvement and a better description
to the #7 (now #5) as
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
> Just the suggestion that as all standards support using %#08x to prefix
> with 0x (prefix output capitalization follows format letter
> capitalization) and would be preferable to hacking the text 0x onto the
> format %08X, doing all of the formatting work with the format flags.
First off, I am
> It is reported by 'configure --help', at the appropriate level (although
> since enable is the default, I probably should have written
> '--disable-doc' here).
I'm sorry if I'm missing anything, but I updated y'day and this is what I see
regarding the doc in configure:
$ ./configure --help |
So? With %X (capital X) the alternate form has the prefix 0X capital, too; and
it's really hard to read.
IDK what is exactly your point that you are trying to make, is my patch somehow
incorrect, or what?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> From: Brian
>
> Add a configure option '--disable-doc' to disable building of the
> documentation by the 'all' target.
>
Can you please also add --disable-doc to "configure --help"? It took me awhile
to figure out which option I should use to skip the doc from building because
it does no longer ignore
> 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:
> >
> > 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
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
1 - 100 of 211 matches
Mail list logo
