On 28/01/2019 09:00, Corinna Vinschen wrote:
Since Microsoft decided to name their own sshd service "sshd", too, we
don't have much choice than to rename our service after 16+ years.
https://github.com/PowerShell/Win32-OpenSSH/issues/1331
My patch has been accepted upstream so starting with
On 22/04/2016 08:02, David Macek wrote:
On 21. 4. 2016 18:01, John Cowan wrote:
David Macek scripsit:
You're assuming LSW will become pre-installed on these workstations and
UoW will become a Windows Store "app". I'm not saying it can't happen,
but it seems unlikely at the moment.
Why
On 03/02/2015 19:50, Thomas Wuillemin wrote:
clang -Wall -Wextra -pedantic -g -O0 dummy.c -o dummy.exe
As a reference point this works fine on FreeBSD with both:-
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
FreeBSD clang version 3.5.1 (tags/RELEASE_351/final
- Original Message -
From: Reini Urban
On Thu, Sep 27, 2012 at 5:26 AM, Steven Hartland wrote:
The following are dangling symlinks after a clean cygwin install updated
today.
/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll
/usr/lib/perl5/5.14/i686-cygwin-threads-64int
The following are dangling symlinks after a clean cygwin install updated
today.
/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll
$ cygcheck -p cygperl5_14_2.dll
Found 1 matches for cygperl5_14_2.dll
- Original Message -
From: Steven Hartland
After a clean install today of cygwin sshd is randomly crashing.
The only trace I can find is in the windows event log which shows:-
The description for Event ID 0 from source sshd cannot be found.
Either the component that raises this event
The following little patch fixes tar under cygwin not ignoring
directory change times.
Without it a simple tar can easily fail.
--- src/create.c.orig 2011-01-07 10:04:33.297364800 -0800
+++ src/create.c2011-01-07 09:51:37.804364800 -0800
@@ -1788,7 +1788,7 @@
/* Original ctime
- Original Message -
From: Steven Hartland
Rebase seems to have no impact on this sshd still randomly crashing
sshd: PID 584: service `sshd' failed: signal 11 raised
I'm able to provoke this at will by running:-
root@testhost:~ cygserver-config
Overwrite existing /etc
- Original Message -
From: Steven Hartland
Rebase seems to have no impact on this sshd still randomly crashing
sshd: PID 584: service `sshd' failed: signal 11 raised
I'm able to provoke this at will by running:-
root@testhost:~ cygserver-config
Overwrite existing /etc
- Original Message -
From: Steven Hartland
More info, adding -e to the command line of the service I get the following
in /var/log/sshd.log:
Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
Accepted publickey for root from 85.236.96.27 port 19861 ssh2
Exception
Quite an old issue, its due to the special handling of .exe files if you search
the archives you'll find lots of mentions of it.
Regards
Steve
- Original Message -
From: Aaron Schneider
$ touch myfile myfile.exe
$ tar -cvf mytar.tar myfile.exe myfile
$ tar -xvf
Just been trying the 5.14.2 that's was available in setup.exe as of
6th June 2012 and the dependencies for LWP are quite broken.
So far I found the following missing dependencies for libwww:-
Warning: prerequisite File::Listing 6 not found.
Warning: prerequisite HTTP::Daemon 6 not found.
- Original Message -
From: Achim Gratz
Steven Hartland writes:
Just been trying the 5.14.2 that's was available in setup.exe as of
6th June 2012 and the dependencies for LWP are quite broken.
I have recompiled all Perl modules in perl_vendor as separate packages
due to (among other
- Original Message -
From: Achim Gratz
Steven Hartland writes:
Cool looking forward to it the new update :)
I don't think that Reini will switch from perl_vendor to unbundled
module packages, at least not for this release. I've posted a link to
my cygport package definitions over
- Original Message -
From: Aaron Schneider
$ touch myfile myfile.exe
$ tar -cvf mytar.tar myfile.exe myfile
$ tar -xvf mytar.tar
Only myfile will be written to the filesystem
Yep, apparently its by design :(
It causes us pain regularly so we would like this fairly
recent change
- Original Message -
From: Christopher Faylor
On Thu, Jul 12, 2012 at 01:39:41AM +0100, Steven Hartland wrote:
From: Aaron Schneider
$ touch myfile myfile.exe
$ tar -cvf mytar.tar myfile.exe myfile
$ tar -xvf mytar.tar
Only myfile will be written to the filesystem
Yep
- Original Message -
From: Christopher Faylor
On Mon, Jul 09, 2012 at 05:23:13PM +0200, notstop wrote:
You must be right in some points, but that is not the exact behavior of
windows command although you pretend it to be (the powershell has a
different behavior). In fact, I can
We're updating our servers to a newer version of cygwin (1.7.15)
from previous 1.7 version and in this version the install of
cygrunsrv (V1.40, Apr 25 2012) fails to correctly prompt for
a user password even though -u username is being specified.
It seems like cygrunsrv maybe checking for an
- Original Message -
From: Steven Hartland
We're updating our servers to a newer version of cygwin (1.7.15)
from previous 1.7 version and in this version the install of
cygrunsrv (V1.40, Apr 25 2012) fails to correctly prompt for
a user password even though -u username is being
If your running Windows 7 or 2k8 are you running the following hotfix, if not
you should try that too, just in case you machine has got a degraded tcp
stack.
http://support.microsoft.com/kb/983528
Regards
Steve
- Original Message -
From: Corinna Vinschen
Sent: Tuesday, January
- Original Message -
From: Corinna Vinschen
Sent: Tuesday, January 10, 2012 4:28 PM
Subject: Re: socket performance (was Re: Building cygwin1.dll)
On Jan 10 15:24, Steven Hartland wrote:
If your running Windows 7 or 2k8 are you running the following hotfix, if not
you should try
- Original Message -
From: Corinna Vinschen
Well, the file I downloaded was a self-extracting zip archive and the
file it contains is called Windows6.1-KB983528-x64.msu, so I'm fairly
certain it's the right one for an AMD64 system.
Windows6.1-KB983528-x64.msu is the file I have here
- Original Message -
From: Jeremy Bopp jer...@bopp.net
All of these combinations avoided the early EOFs problem no matter how
many times I repeated my testing. As cgf said, this does appear to be a
problem in Cygwin's pipe code, but it's very strange that it only seems
to be triggered
Just been debugging a very strange issue where tar was
reporting file changed as we read it for directories
which aren't actually seeing any changes.
It turns out that the value of st_size returned by a call
to fstatat on a directory can change even though there
have been no changes at all to
- Original Message -
From: Eric Blake
On 01/07/2011 11:21 AM, Steven Hartland wrote:
What file system is this on? Someone else reported the same behavior
for Samba share on QNX through Virtual PC. - if the problem is limited
to just a subset of (known-buggy) file systems, it would
- Original Message -
From: Larry Hall (Cygwin)
Just NTFS I'm afraid nothing special.
You can see the behaviour with ls -l as well, as you would expect.
A simpler, which may help is:-
ls -l
drwxr-xr-x 1 test test 0 Oct 20 14:09 testdir
find testdir /dev/null # lots of files
ls -l
- Original Message -
From: Larry Hall (Cygwin)
Here it takes about 2 - 5mins for what ever is causing the 0 size after a
find to start to happen. Prior to that after the find all dirs show 8192 for
size in an ls.
Ah, that's interesting. I see no such time-lag here.
Just to be 100%
- Original Message -
From: David Mastronarde m...@colorado.edu
You CAN'T have a directory and an executable sharing the same name on
Linux, so why should you try the same thing on cygwin? Given that
cygwin attempts to handle '.exe' as a necessary evil, and tries to
recognize
- Original Message -
From: Eric Blake ebl...@redhat.com
On 01/04/2011 12:01 PM, Steven Hartland wrote:
It really feels like so called consistency is being enforced over
functionality which is sad as I always though cygwin's goal was to make
Unix look and feel under windows
We're seeing some strange behaviour with tar under cygwin
when its start point is a disk mounted under a directory.
The result is:-
We have the following disk layout:
disk1: c:\dir1\dir2
disk2: d:\ c:\dir1\dir2
Now when in c:\dir1 and extracting the tar which contains:-
dir2/subdir1/file1
- Original Message -
From: Christopher Faylor
This looks like either a premature return from a syscall or libcall, or like a
genuine race in the system.
Has anyone seen similar things?
Yes and you seem to have nailed the problem - it happens when a virus checker
hooks into a
- Original Message -
From: Christopher Faylor
What I suggest isn't that usefull when you think to base all
DLL that have been installed by setup.exe. It becomes usefull in the
moment the user starts to compile his own DLL especially if he used
scripts to control compilation. To compile
- Original Message -
From: Dave Trollope
I too have seen this behaviour on both my work and home systems. Whats
interesting is I ran cygcheck -c on each when exhibiting this problem
and it said OK for the cygwin package.
Just had this same behaviour so setup is still broken as is
Unless I'm going mad it seems either cygwin itself, perl, DBI or DBD::mysql
have been broken in 1.7.1 or the update to perl 5.10.
I'm running a script which has been working here for years
but is now broken and from what I can tell the issue is
fairly fundamental so I'm currently suspecting an
Been trying a few things and going back from perl 5.10.1-2 to
perl 5.10.1-1 fixes the issue, or at least I can now no longer
reproduce the problem readily.
Looking at the differences seem to be the change in flags from
-Dmad=y - -Doptimize=-O3 so we could be looking at a
compiler bug?
One thing
Just to be 100% clear its not the fact that the script errors, its the fact
that the permissions after the initial DOS pathed chmod doesn't actually set
the permissions correctly and doesn't throw any error.
Regards
Steve
- Original Message -
From: Dan Offord
- Original Message -
From: Corinna Vinschen
That's by design. When you use Win32 paths, instead of POSIX paths,
you will get Win32 default permission handling. Or, in other words,
for all DOS paths the mount mode is noacl.
Ok that begs the questions:-
1. What was the reasoning
- Original Message -
From: Corinna Vinschen
Win32 path - No POSIX path - no POSIX permissions.
So then why does it have any permissions support at all? By allowing
permissions to be read and obeyed, but not written, your sending out
very much mixed messaging which is confusing at
Just been chasing my tail for hours trying to figure out why the permissions
on a file weren't being set even though no error was being thrown.
It turns out that giving a dos like path to chmod in perl under 1.7
although doesn't error it doesn't do anything either.
Here's my little test case:
- Original Message -
From: grkuntzmd
Are you using push or pull? In other words, are you running rsync on the
Windows host and sending to the Linux host, or are you running rsync on the
Linux host and retrieving files from the Window machine? It is the latter
that hangs.
Also are
- Original Message -
From: Christopher Faylor
On Wed, Nov 18, 2009 at 11:28:27PM -, Steven Hartland wrote:
After a while of running one of our perl scripts errors with
the following on windows 7 / 2k8 r2
3 [sig] perl 8296 C:\cygwin\bin\perl.exe: *** fatal error - couldn't create
After a while of running one of our perl scripts errors with
the following on windows 7 / 2k8 r2
3 [sig] perl 8296 C:\cygwin\bin\perl.exe: *** fatal error - couldn't create
signal pipe, Win32 error 1
This is with cygwin:-
CYGWIN_NT-6.1-WOW64 blade24 1.7.0(0.212/5/3) 2009-09-11 01:25 i686
- Original Message -
From: Corinna Vinschen
On Aug 8 03:16, Steven Hartland wrote:
If you extract a tar.gz file with an executable file and
an excitable file of the same name but with the .exe extension
on extract the .exe file is inexplicably deleted.
e.g.
tar -xvzf test.tar.gz
If you extract a tar.gz file with an executable file and
an excitable file of the same name but with the .exe extension
on extract the .exe file is inexplicably deleted.
e.g.
tar -xvzf test.tar.gz
mydir/myexe.exe
mydir/myexe
ls myddir
myexe
rm -rf mydir; tar -xvzf test.tar.gz; mydir/myexe.exe
We've always found rsync on cygwin unreliable when used with ssh, so much so
that I wouldn't advise it to anyone. If you can do away with ssh and use daemon
mode then you'll likely have more joy. Alternatively try sfu's version which
apart from the 2GB file limit works well.
Regards
Steve
- Original Message -
From: Dat Head
On Sun, Aug 2, 2009 at 5:57 AM, Steven Hartland wrote:
We've always found rsync on cygwin unreliable when used with ssh, so much so
that I wouldn't advise it to anyone. If you can do away with ssh and use
daemon mode then you'll likely have more
- Original Message -
From: Dat Head
there is only one machine involved - i am just copying files from one
place to another.
no rsyncd. rsync -avx /cygdrive/f/foo /cygdrive/g
Ahh ok.
Try adding --progress, we've had that help in the past, dont ask why ;-)
Regards
Steve
--
- Original Message -
From: Corinna Vinschen
On Jul 29 19:25, Christopher Faylor wrote:
On Wed, Jul 29, 2009 at 03:32:28PM +0800, Haojun Bao wrote:
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes:
On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote:
I
In the latest version of ssh-user-config from 1.7 it uses the method
csih_error_multiline which doesn't exist, I assume this should be
csih_error_multi from:
/usr/share/csih/cygwin-service-installation-helper.sh
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Just wanted to confirm upgrading to 1.7.0-25 ( with the SEH fix )
fixes this issue under Windows 2008 R2.
Thanks again to those involved in identifying and fixing this issue.
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ:
When installing perl modules e.g. Bundle::CPAN from cpan the process
is constantly dogged by rebase issues, where you have to kill off
the perl process, as it never gives in try, and rebaseall.
Is there anyway to help avoid this?
$ uname -a
CYGWIN_NT-6.1-WOW64 ibm 1.7.0(0.212/5/3) 2009-07-24
Fantastic guys!
I would just like to take this opportunity to express my thanks to all
involved in this, especially for the SEH fix and mount -a enhancement!
I will be trying this over the weekend :)
Regards
Steve
- Original Message -
From: Corinna Vinschen
Having a strange issue where process creation seems to
fail for no good reason. I think I've hit a process
creation limit.
Googling around I found:
http://www.cygwin.com/ml/cygwin/1998-01/msg00249.html
Is it still the case that cygwin is limited to a max
number of processes and is this on a
- Original Message -
From: Christopher Faylor
The process limit is 256 per program. You should see an EAGAIN errno
being set if the process limit is hit. The overall per-user process
limit is controlled by Windows.
Hmmm don't quite follow you there Chris, could you elaborate on
- Original Message -
From: Christopher Faylor
Hmmm don't quite follow you there Chris, could you elaborate on what you
mean by per program?
Does per-process make it any clearer? Each process can start 256
subprocesses.
Yes that does, thanks :)
--
Problem reports:
- Original Message -
From: Christoph Herdeg
Great to see that at least you guys have fun and enjoy yourselves. I very
hope to have made your days. Thank you again for your superb help! You're
great people!
The way you answer to people seeking for help speaks for itself. I hope the
- Original Message -
From: Christopher Faylor
The point is that this is generating the equivalent of a SEGV without
ever hitting Cygwin's SEH code. Setting a breakpoint on the line
would likely just show you the call stack but would not provide any
insight into why the myfault was not
Having read:
http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table
I'm still at a loss how to activate newly added mount points
from fstab?
The standard Unix paradigm would be mount -a or mount target
but none of these work. The only way I've found is to restart
the cygwin prompt which is
- Original Message -
From: Dave Korn
(gdb) b 113 if ((*object) == 0)
No symbol object in current context.
(gdb)
Ah, that's bad. It might work on a DLL compiled with -O0 -g, but here we
have a problem that the function gets inlined everywhere it's called. So
instead I set an
- Original Message -
From: Christopher Faylor
Any I missing something or has this functionality just been
overlooked?
Overlooked == not implemented.
;-)
Something that's planned?
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Been looking around but cant find any mention of it so asking here:
Is there a known issue with the latest 1.5.25 + perl 5.10 threads,
as doing anything with threads here causes an instant crash.
[test]
#!/bin/perl -w
use warnings;
use strict;
use threads;
print STDERR Testing threads...\n;
my
/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.
- Original Message -
From: Steven Hartland kill...@multiplay.co.uk
To: Cygwin List cygwin@cygwin.com
Sent: Tuesday, July 14, 2009 5:44 PM
Subject: perl 5.10
- Original Message -
From: Dave Korn dave.korn.cyg...@googlemail.com
sub dothread { print STDERR I'm a thread!\n }
[/test]
WFM with perl 5.10.0 on both 1.5 and 1.7.
Thanks Dave, maybe a Windows Server 2008 R2 64bit issue?
Regards
Steve
--
Problem reports:
- Original Message -
From: Corinna Vinschen corinna-cyg...@cygwin.com
On Jul 14 14:55, Christopher Faylor wrote:
On Tue, Jul 14, 2009 at 07:18:44PM +0100, Steven Hartland wrote:
On Tue, 14 Jul 2009 19:16:46 +0100, Dave Korn wrote:
sub dothread { print STDERR I'm a thread!\n }
[/test
- Original Message -
From: Corinna Vinschen corinna-cyg...@cygwin.com
... and the script works fine on Windows 7 Build 7201 running under
Cygwin 1.7.
No joy here with 1.7 either, just crashes out instantly.
Running Windows Server 2008 R2 Standard 64bit build 7100 on dual E5520
with
- Original Message -
From: Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com
No joy here with 1.7 either, just crashes out instantly.
Running Windows Server 2008 R2 Standard 64bit build 7100 on dual E5520
with 18GB RAM showing 16 cores if that may be of interest.
gdb is
This may or may not help:
According to VC++ debugger it always dies with:
Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
reading location 0x0004.
According to gdb 0x610d089d = thread.cc:113
So running it through gdb it hits this break point ~ 280 times before
:56AM +0100, Steven Hartland wrote:
This may or may not help:
According to VC++ debugger it always dies with:
Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
reading location 0x0004.
No, sorry, it really doesn't help. The VC++ debugger doesn't know how
to handle
rsync over ssh and cygwin don't play nice and likely never will. Either
avoid using rsync or use it in daemon mode avoiding ssh which is where
the problem really lies ( the interaction between rsync and ssh ).
A good alternative to cygwin for this is SFU but be aware that most
versions only
When given an invalid mask such as 24 cygwin's inet_pton
returns 1 instead of either 0 or -1 signifying an error.
This causes rsync to fail access checks for CIDR notation.
Regards
Steve
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
- Original Message -
From: Corinna Vinschen
I've attached the output from whoami in both cases. A privaledege
missing from the sshd_server user may be? Note: ssh was installed
with a slightly older than latest version of cygwin so if this has
changed to support 2008 recently that could
- Original Message -
From: Corinna Vinschen [EMAIL PROTECTED]
After further looking into this issue I fear I can't do anything against
that in Cygwin 1.5.25 anymore. There is a strange privilege issue when
using impersonation tokens starting with Windows Vista. The root of the
- Original Message -
From: Steven Hartland
Other than that, maybe using the (not yet production) Cygwin 1.7 is
an option for you. You can install a 1.7-based distro over your 1.5
distro using another setup.exe: http://cygwin.com/setup-1.7.exe
I'll give this a shot in a bit and let you
- Original Message -
From: Corinna Vinschen
This seems to work fine, is there anything I should be aware of if we
looked to use this in production environment?
The mount points are now stored in /etc/fstab and /etc/fstab.d/$USER
instead of in the system and user registry. There are
- Original Message -
From: Corinna Vinschen
On Jul 7 17:12, Steven Hartland wrote:
I know its cheaky but I dont suppose you could shed any light on my
other thread regards 2008 support:-
apache crashing on windows 2008 when listening on localhost
Sorry, but no. There's other work
- Original Message -
From: Christopher Faylor
On Thu, Jul 03, 2008 at 11:22:03PM +0100, Steven Hartland wrote:
Hope this gets through the lists broken spam detection, and helps id the
issue.
How to Win Friends and Influence People...
Wasn't meant to be derogatory or anything
- Original Message -
From: Christopher Faylor
Wasn't meant to be derogatory or anything but having to send each mail
several times with slightly different wording, layout, subjects as they
keep bouncing due to being detected as spam is quite annoying.
I see two blocks from you in the
- Original Message -
From: Christopher Faylor
If you think you are being blocked inappropriately, do what the bounce
message tells you and send email to postmaster. And, if at all possible,
leave out words like annoying and broken.
When this happens there is no real bounce just our
- Original Message -
From: Corinna Vinschen
That's weird. Cygwin always enables the backup and restore privileges
if they are available. The whoami printout in your previous mail
shows that the privilege is in the token. But the above code shows
that the AdjustTokenPrivileges() call
- Original Message -
From: Steven Hartland
That's weird. Cygwin always enables the backup and restore privileges
if they are available. The whoami printout in your previous mail
shows that the privilege is in the token. But the above code shows
that the AdjustTokenPrivileges() call
I'm trying to get our standard apache setup to run under windows 2008
and I've hit a strange issue it seems as soon as I have the following
in httpd.conf apache crashes out under Windows 2008 server:-
Listen 127.0.0.1:81
Removing this line seems to enable apache to at least fire up without
Running chmod under 2008 simply doesnt seem to work here,
which is really strange.
[EMAIL PROTECTED]/: id
uid=500(root) gid=513(None) groups=513(None),544(Administrators),545(testuser)
[EMAIL PROTECTED]/tmp: touch test
[EMAIL PROTECTED]/tmp: chown testuser test
chown: changing ownership of
- Original Message -
From: Corinna Vinschen
Works fine for me on 2008 so I assume some local setting which
disallows this. Did you remove the Back up privileg and directories
privilege from the admin's account, by any chance?
The info from whoami /all indicates that you are
- Original Message -
From: Corinna Vinschen
[EMAIL PROTECTED]/: grep testuser /etc/group
testuser:S-1-5-32-545:545:
Huh? Why did you do that? This is the entry for the Users group.
It doesn't seem to make sense to rename it for Cygwin.
Purely for compatibility reasons and has
Unfortunately rsync is a lost cause on cygwin until the underlying pipe
issue or whatever it is can be fix. Give this has been about for years
I wouldn't hold you breath for this. Look for an alternative like
rsync daemon mode or using SFU.
N.B. Its not just rsync scp under cygwin is also
Its very unreliable over ssh, constantly locks up part way transfers, so if you
do use it I'd recommend using daemon mode.
Alternatively use SFU which doesn't have the issues.
Regards
Steve
- Original Message -
From: Sisyphus [EMAIL PROTECTED]
Is there an rsync package for
Do you have any antivirus on the Vista machine?
- Original Message -
From: John Cooper
Any ideas what might be causing the slowdown and how I might avoid it?
This e.mail is private and confidential between Multiplay (UK) Ltd. and the
- Original Message -
From: Dave Korn
Trying to get rsync running on Windows. It seems to hang when
transferring a certain excel spreadsheet. As far as I can tell the
spreadsheet is not open by anybody and is copyable using `dd`. Hence,
cygwin can read it just fine. Any idea why this
- Original Message -
From: Dave Korn
Off the top of my head, I thought these sorts of problems usually cropped up
only when transferring huge amounts of data or large file sets?
From our experience the larger the number of files and the larger
the transfer the higher the chance of
- Original Message -
From: nenad [EMAIL PROTECTED]
Hey nenad fire up msconfig and limit the CPU's to 1 in your new
rig and see if that makes any difference. If it does then there
is something about dual which is causing it if not you've
eliminated it as the cause and can start looking
Gary R. Van Sickle wrote:
1. Does ZoneAlarm cause the same volume of havok with other software
as it does with Cygwin? The equation appears to be Cygwin +
ZoneAlarm = Disaster, but I have a hard time believing that it isn't
really a system of equations more along the lines of
I've setup and environment using scponly-4.6 where by I have
the following:
/home/user1/required shared dir
What I've done to get required shared dir is to actually
mount it under cygwin e.g.
mount c:/shareddir /home/user1/shareddir
Unfortunately when the user logs in using sftp shareddir
is
Christopher Faylor wrote:
On Mon, May 01, 2006 at 11:11:57PM -0700, Yitzchak Scott-Thoennes
I'm having problems with rsync'ing perl seeming to hang that didn't
happen with 1.5.18/9 or snapshots up to 20060329. I'll try to post
cygcheck output soon.
Corinna changed ssh recently. Are you
Corinna Vinschen wrote:
freebsd1 ssh cygwin1
cygwin1 echo 1 /tmp/test.txt
cygwin1 cat /tmp/test.txt
1
cygwin1 exit
freebsd1 ssh cygwin1 cat /tmp/test.txt
*** no output ***
Looks like its just not flushing the output at someone point in the
reworked code.
I just tried it a couple of times and
- Original Message -
From: Corinna Vinschen [EMAIL PROTECTED]
Damn (sorry).
It works fine for me with the latest snapshot. I tried Peter's example
with 1000 files and rsync over ssh works like a charm for me. Sigh.
This is really a tricky problem. What I could do to circumvent
Corinna Vinschen wrote:
It works fine for me with the latest snapshot. I tried Peter's
example with 1000 files and rsync over ssh works like a charm for me.
Sigh.
This is really a tricky problem. What I could do to circumvent this
at least for connections over ssh is to upload an OpenSSH
Steven Hartland wrote:
Good news this does fix the issue. I've just successfully done
an rsync of ~1G ( 1700 files ) with no problem at all.
Also note that due to the existing performance issues in ssh ( I've
still not had chance to dig more about that sorry ) there is NO
noticable slowdown
- Original Message -
From: Dave Korn [EMAIL PROTECTED]
That's a known issue, and one which I'd like to try and work on
...
Unfortunately it doesn't seem possible to set a breakpoint on that function
in either windbg or gdb, so it looks very much like I'm gonna hafta break out
the full
- Original Message -
From: Corinna Vinschen [EMAIL PROTECTED]
maybe, the amount of files has to be increased in order to provoke the
error. I have run my script with only 100 instead of 300 files and it
works. Maybe, you can give it a try.
I did and I could reproduce it. Thanks for
- Original Message -
From: Christopher Faylor
Would it help the base rsync case do you think Corinna? Should I try
the snapshot here to check, if so what's the snapshot indent and where's
the best place to obtain it from, not used snapshots before but if
it would help you guys test worth
1 - 100 of 150 matches
Mail list logo
