>> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
>
>Not yet, all stuff for the Cygwin install of the ms-nfs41-client goes
>into the Cygwin /bin && /sbin dirs.
Let's try for NEVER. 3rd parties have no business polluting the operating
system. If this is MS code or closely
can you turn stunnel debug up higher?also post your stunnel.conf?
Beyond that, why something this convoluted when you could use ssh
port-forwarding by way of the remote Stunnel endpoint? Or use Stunnel as a
SOCKS proxy and configure SSH client to connect that
> If you really suspect some AV problems, it may help to try the> uncompressed
> setup executable, available from [1]
Huh, when did this start? Nobody pays by BW anymore so what was the rationale
behind a "self altering" executable? No wonder it would experience havoc in an
A/V environment
> The problem seems to be that OpenSSH does not even arrive at checking the
>home diretory> or the .ssh directory. It starts checking every directory in
>the path and fails already at "/cygdrive/c/Users"
I don't think we can win an argument with Theo over how misguided and
unnecessary meddling
> This breaks many applications such as the java runtime among others.
In any event "unreadable files" is a problem all over the place if I use
Cygwin's /usr/bin/ln to create links. That's why I was forced to write a
wrapper. Even if 'JUNCTION' is false/misleading as to the root cause, plenty of
> Cygwin does not create symlinks as junctions. No idea where you got that
> idea.
$ echo $CYGWINwinsymlinks:nativestrict
$ /usr/bin/ln -s default.GGG6q test1
01/08/2024 01:24 PM test1 [...]Type=File
$ (unset CYGWIN; /usr/bin/ln -s default.GGG6q test2.nocygwin)
01/08/2024 01:25 PM
> For instance: Getting rid of .lnk files isn't easy with backward
>compatibility in mind.
screw backward compatability! :)Why carry around bandaids on bandaids for an OS
that is 10 years out of support?
Obviously not ripe for 3.6 or maybe even 3.7, but at some point we should just
put a stick
On Wednesday, January 3, 2024 at 04:10:56 AM EST, Cedric Blancher via Cygwin
wrote:
> general": What really sucks is the filesystem inode operations and
> file name lookup, e.g. /bin/find are absurdly slow because of
> the link emulation and the inflation of syscalls caused by it - just
...>If
> The cause is apparently that Cygwin's strverscmp implementation wasborrowed
> from musl libc
would it make sense to use git submodules when "borrowing" code so the upstream
reference is not lost, and keeping it abreast is relatively trivial exercise?
--
Problem reports:
> I've got "export EDITOR=vi" in my .bash_profile, so anytime $EDITOR is
> called I want the huge version of vim.
Then set EDITOR=
If you want to cheat and only use 'vi' then you need to walk the dependency
chain and/or search_for_binary mechanism employed by the SHELL to find the
correct
>> No, because that's system-wide.
>> Vi vs Vim is a personal choice. Also alternatives is for supporting multiple
> Most of us run Cygwin on a device called a /Personal Computer/ that allows us
> to
> make our own choices about OS, desktop UI, services, and configuration. ;^>
yeah, yeah I
> I'd say vi/vim needs to be put under /etc/alternatives
No, because that's system-wide.
Vi vs Vim is a personal choice. Also alternatives is for supporting multiple
versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin and
the other in /usr/local/bin just as an example.
> Would you please let me know how to make an /etc/alternatives for vi/vim?
did you install the alternatives package? I just use aliases (actually I set
EDITOR=xxx) after I enumerate the editors I consider worthy of inclusion and
resident. What DOES need nuking is the forced alias in
and /etc/profile.d/vim.sh has this bit:
if [ -n "$BASH_VERSION" -o -n "$KSH_VERSION" -o -n "$ZSH_VERSION" ]; then
# for bash and zsh, only if no alias is already set
alias vi >/dev/null 2>&1 || alias vi=vim
fi
someone needs to be smacked good and hard for that.
--
Problem reports:
That said, cygwin now uses junctions which is annoying and not all that
compatible with all aspects of the windows ecosystem. So I wrote a wrapper
script that replaced ln with calls to mklink. Much better.
https://github.com/tb3088/shell-environment/blob/master/.functions_os.CYGWIN_NT#L9
--
>> Cygwin never creates Windows Directory or Filesystem Junction reparse points,
>> and by default it uses its own version of Unix path symlink files, preceded
>> by
>> a flag ("magic cookie") value, and with system attribute, to allow
>> compatibility with FAT file system limitations, or else
AFAIK no. what I do is re-implement 'ln' with a wrapper because the Cygwin
behavior (Junctions) was driving me up the wall.
https://github.com/tb3088/shell-environment/blob/ccf7aa161899c2c4ebe2d9e980e674bc726a3ef3/.functions_os.CYGWIN_NT#L9
"In the information society, nobody
The fork() bomb is still a problem with 3.3.4 but it's "benign" under <=3.2.0
because a Ctrl-C reaps the call stack. Something changed significantly between
how processes are spawned apparently.
But the CAUSE of the fork() bomb was the combined use of CYGWIN_NOWINPATH=1 and
this fragment in my
> Can you try the suggestions I made in my reply
>https://cygwin.com/pipermail/cygwin/2022-February/250790.html ?
sorry, no. Even though I have Admin I am unable to override this. Please note
that all previous versions of cygwin1.dll (<3.3.3) are not interfered with.
Though if this is indeed
CMD.exe and since with NOWINPATH set CMD.exe can't be found so it just fork
bombs?On Friday, April 29, 2022, 02:25:38 PM EDT, matthew patton via Cygwin
wrote:
--- Process 25852 created--- Process 25852 loaded
C:\Windows\System32\ntdll.dll at 7fffa01b--- Process 25852 loaded
C
--- Process 25852 created--- Process 25852 loaded
C:\Windows\System32\ntdll.dll at 7fffa01b--- Process 25852 loaded
C:\Windows\System32\kernel32.dll at 7fff9eef--- Process 25852 loaded
C:\Windows\System32\KernelBase.dll at 7fff9db0--- Process 25852 loaded
C:\Program
I had to revert to 3.3.3-1 to restore functionality.with 3.3.4 invoking cygpath
would cause an Access Violation Exception (0x05) and kill the thread so that I
couldn't even do a 'cygpath --help'
All of a sudden I also am experiencing fork bombs if I type an invalid command.
eg. type 'l'
I use the Windows version but had to write a wrapper since AWS CLI doesn't
understand cygwin style paths in environment variables (not new).
https://github.com/tb3088/shell-environment/blob/master/.functions_aws#L14
On Friday, November 26, 2021, 10:34:26 AM EST, Eliot Moss
wrote:
On
have you tried applying the notable permissions from this to your 'ftp' windows
user?https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/user-rights-assignment
On Monday, June 28, 2021, 06:48:18 PM EDT, David Oppenheim
wrote:
I have debugged
On Tuesday, February 16, 2021, 12:05:32 PM EST, Rodney Kissee via Cygwin
wrote:
> My company identifies netcat as a hacking tool and is requiring it to be
> removed from our version of Cygwin.
aside from beating the moron with clue-by-four or locking him in the tape safe,
rename binary
On Sun, Feb 7, 2021 at 4:13 PM Jon Turney wrote:
>> It seems that gdb wants to run 'iconv -l' to list the available encodings.
>>
>> It looks like perhaps an upstream bug that gdb outputs nothing when
>> iconv can't be found (rather than using the default encoding?).
> the lack of a backup
On Thursday, January 21, 2021, 05:29:27 PM EST, Tord Andreasson via Cygwin
wrote:
> I tried "strace -o /tmp/gdb.strace /usr/bin/gdb --version" and indeed there
>are lines with 37 error messages in it. Since the trace file is large (2MB)
$ Err_6.4.5.exe 0xC034 says:
On Thursday, January 21, 2021, 01:30:41 PM EST, Takashi Yano via Cygwin
wrote:
On Thu, 21 Jan 2021 13:13:56 -0500
Ken Brown wrote:
> # when leaving the console clear the screen to increase privacy
> if [ "$SHLVL" = 1 ]; then
> [ -x /usr/bin/clear ] && /usr/bin/clear
> fi
That should be
On Thursday, January 21, 2021, 10:49:14 AM EST, Martyn B
wrote:
> 1) understand why this happens. - Is this the Cygwin standard behavior?
Not in the slightest.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
On Sunday, January 17, 2021, 02:41:35 PM EST, Brian Inglis
wrote:
> Sorry, it's been a few years now - there were a few issues testing various
> paths > using various directories and links that neither readlink nor
> realpath resolved
> absolutely and correctly, so I added the cygpath to
On Sunday, January 17, 2021, 02:44:37 PM EST, Achim Gratz
wrote:
>matthew patton via Cygwin writes:
>> can we fix setup.exe to read STDIN with '-P', like so?
>> echo 'pkg1,pkg2,pkg3' | setup.exe -P -
> You probably forgot that setup is a Windows program. besides, yo
can we fix setup.exe to read STDIN with '-P', like so?
echo 'pkg1,pkg2,pkg3' | setup.exe -P -
and even more useful if the argument can be space delimited.setup.exe -P pkg1
pkg2 pkg3or if that's too muchsetup.exe -P pkg1 -P pkg2 -P pkg3
--
Problem reports: https://cygwin.com/problems.html
On Friday, January 15, 2021, 12:48:16 PM EST, Ken Brown via Cygwin
wrote:
> but it would be appreciated if you would confirm this by testing a snapshot.
I have confirmed that running snapshot build Cygwin1.dll from 2021-01-13
handles symlinks in the PATH as expected.
--
Problem reports:
On Friday, January 15, 2021, 12:09:30 PM EST, Brian Inglis
wrote:
> Given that you have the same symptom, it is possible that Git-Bash or
> something > else you are running in Windows is creating symlinks somewhere,
I only installed Git-Bash out of desperation and it's msys.dll (fork of
/.functions#L144
On Friday, January 15, 2021, 11:36:28 AM EST, matthew patton via Cygwin
wrote:
Ken Brown wrote:> Do you by any chance have symlinks in your PATH?
Yes, the first and 3rd entries are symlinks. I've had these symlinks in my PATH
for years.
/home/MP1116/.aws/YYY/bin:/h
Ken Brown wrote:> Do you by any chance have symlinks in your PATH?
Yes, the first and 3rd entries are symlinks. I've had these symlinks in my PATH
for years.
/home/MP1116/.aws/YYY/bin:/home/MP1116/bin -> .WPHOME/bin/
.aws -> .WPHOME/.aws/.WPHOME -> Dropbox/Work_Projects/XXX
#/etc/fstabC:/Users
ring a bell with anyone?
C:\Users\mp1116\Downloads>Err_6.4.5.exe 0xc279# for hex 0xc279 /
decimal -1073741191 STATUS_IO_REPARSE_TAG_NOT_HANDLED
ntstatus.h# The layered file system driver for this IO tag did not# handle
it when needed.# as an HRESULT:
ok, so can someone do the following on their installation? I've narrowed it
down to the invocation of git-core/git.exe or any of the other git-core/git*
binaries. I get a Windows dialog box no less, with "The application was unable
to start correctly".
100(1) $ strace
Andrey wrote:> 1. Try rebasing your Cygwin install.
deleted cygwin64 and installed to \cygwin. Immediate failure. No apparent grace
period like before.
> 2. See if your antivirus is interfering.
Had corporate IT put me in a special exclusion group (supposedly) to no avail.
See #1
On Friday,
Every recent version that I can remember has been missing the most important
file of all: /usr/share/bash-completion/bash_completion
Why? What is wrong with the packaging process if we're building from the
source? The origin has always lived at
I've been using cygwin since like 20 years ago and do everything in it. A
couple days ago my Git program mysteriously stopped working. I can see
(GIT_TRACE=1) it invoke SSH and HTTPS connections just fine but it fails with a
short-read/write when it's time for pack or unpack. Baffled I
The 'pidof' command doesn't work with Cygwin's very crippled version of
/bin/ps. Specifically 'ps' doesn't understand '-o' nations whereas 'procps'
does.
Either 'pidof' needs to account for the Cygwin 'ps' not being remotely as
capable as the Linux 'ps' command and alter invocation
> I think refusing an account manually and deliberately disabled by an
> admin makes lots of sense.
Why is this even a discussion? You *ALWAYS* refuse a login to an account that
is disabled, locked out, or has an expired password or failed any of the other
criteria that might be in effect
I agree this may not be a bug as such but would VERY much like it fixed. In
extreme cases I have to resort to rsync in/out of WSL to do builds or make sure
to only do relative paths. That there already is a patch set should make this
an easy think to undertake.
--
Problem reports:
https://github.com/tuna/rsync/blob/master/configure.ac#L981
Looks like it was short-circuited to use Solaris ACLs. I'll send the RSYNC guys
a patch.
Defeating the case statement does pick up Posix ACLs.
$ grep -i acl config.status
S["LIBS"]="-lacl "
D["HAVE_SYS_ACL_H"]=" 1"
Many of the headers in 'sys' include their counterparts from 'cygwin'. Why is
acl.h special? I see the comment on line 25 but I'm missing the point, I guess
- not seeing the collisions.
'cygwin/acl.h' is a very important file. Granted I don't normally compile much
from source under Cygwin but
46 matches
Mail list logo
