Re: HEADSUP: SSHD service rename
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 OpenSSH 8.0, newly installed Cygwin sshd services will be called "cygsshd" by default, unless Microsoft renames their service yet :} Of course, systems with already installed Cygwin sshd service will keep the service name, even after an update to OpenSSH 8.0. As some people (including myself) already experienced, an update of your W10 system to 1809 may break your sshd service. The OS update apparently overwrites an existing sshd service with its own sshd service without asking. You can just remove the Windows sshd with $ cygrunsrv -R sshd and reinstall Cygwin sshd, or you reinstall Cygwin sshd under another name: $ ssh-host-config -n cygsshd (pre OpenSSH 8.0) $ ssh-host-config (OpenSSH 8.0 or later) Sorry for the hassle, Corinna Thanks for the heads up its a real pain MS did that, caused me issues a few times. Also watch out for broken firewall rules after this change. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: native Linux userland in Windows 10
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 unlikely? That is exactly what is the case, if you are running the current alpha build of Windows 10. Build #14316? You have to switch to developer mode, then install the subsystem which is a "Windows feature". Both require administrator privileges IIRC. Then you can run `bash` or `lxrun /install` to download the Ubuntu tarball, allegedly from the Store. Until I can go to the Store app on a clean Windows install, write "Ubuntu" and click on Install, I won't consider UoW as "available through the Windows Store" as Warren Young wrote. You also need a huge pinch of good luck as the process is flaky as hell, often failing to present any preview builds at all. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with vprintf () in Clang 3.4.2
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 225668) 20150115 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2-3 installs broken symlinks
- 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/CORE/cygperl5_14_2.dll $ cygcheck -p cygperl5_14_2.dll Found 1 matches for cygperl5_14_2.dll perl/perl-5.14.2-3 Larry Wall's Practical Extracting and Report Language Yes, I already know since every rebase prints this warning. It's just a packaging artefact, does no harm and will be fixed in the next update. Yer thanks was just making sure people where aware :) Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl-5.14.2-3 installs broken symlinks
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 perl/perl-5.14.2-3 Larry Wall's Practical Extracting and Report Language Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clean cygwin install sshd crashes
- 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 is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: sshd: PID 2940: service `sshd' failed: signal 11 raised I'm going to try a rebase to see if that fixes it but I've never seen this before, is there a known issue with the latest version? Rebase seems to have no impact on this sshd still randomly crashing sshd: PID 584: service `sshd' failed: signal 11 raised Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Patch to fix tar directory access time changes under cygwin
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 will change if the file is a directory and
--remove-files is given */
!(remove_files_option is_dir))
- || original_size final_stat.st_size)
+ || (!is_dir original_size != final_stat.st_size))
{
WARNOPT (WARN_FILE_CHANGED,
(0, 0, _(%s: file changed as we read it),
Would be good if this could be included in the offical port
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clean cygwin install sshd crashes
- 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/cygserver.conf file? (yes/no) yes Connection to testhost closed by remote host. Connection to testhost closed. Where to go from here? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clean cygwin install sshd crashes
- 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/cygserver.conf file? (yes/no) yes Connection to testhost closed by remote host. Connection to testhost closed. Where to go from here? 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: STATUS_ACCESS_VIOLATION at eip= eax= ebx= ecx=0028D000 edx=0004 esi= edi=0028A380 ebp=010C esp=0028A330 program=C:\cygwin\usr\sbin\sshd.exe, pid 4764, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0 [main] sshd 4764 exception::handle: Error while dumping state (probably corrupted stack) I've tried by /bin/rebaseall and /bin/peflagsall no difference :( To confirm OS is Windows Web 2008 R2 Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clean cygwin install sshd crashes
- 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: STATUS_ACCESS_VIOLATION at eip= eax= ebx= ecx=0028D000 edx=0004 esi= edi=0028A380 ebp=010C esp=0028A330 program=C:\cygwin\usr\sbin\sshd.exe, pid 4764, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0 [main] sshd 4764 exception::handle: Error while dumping state (probably corrupted stack) I've tried by /bin/rebaseall and /bin/peflagsall no difference :( To confirm OS is Windows Web 2008 R2 Ok problem solved with the latest snapshot. Given the seriousness of the issue, might be worth rolling a new release sooner rather than later. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tar won't extract all files when a file with exe extension precedes the same without extension inside the archive
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 mytar.tar Only myfile will be written to the filesystem -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
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. Warning: prerequisite WWW::RobotRules 6 not found. Warning: prerequisite HTTP::Negotiate 6 not found. Although this may be expected behaviour, I wanted to highlight the fact that quite a few packages require perl yet have hardcoded dependencies on 5.10.x so setup ends up messing up the install when ever its used if you let it correct dependencies :( Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
- 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 things) problems with LWP. Cool looking forward to it the new update :) Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
- 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 in cygwin-apps if you want to compile those packages yourself. If you don't create your own setup.ini files, it's probably not much use. You can always use cpanminus to bootstrap LWP to a newer version locally. Unfortunately the current perl_vendor install is so broken cpan won't allow you to fix it with simple install unless you know the exact missing modules and just breaks in some very strange and random ways. Like missing protocol for ftp in LWP However the perl_vendor was created it resulted in many missing dependencies. I don't mind a block install via perl_vendor but each module installed by that option should include all of its dependencies otherwise its worse than having nothing at all. We'd already updated Bundle::LWP via CPAN but its the dependencies of the dependencies which are missing so they didn't get fixed. Our fix in the end, so others know, was to use:- force install LWP::Protocol::ftp This seemed to force all dependencies in the hierarchy to be rechecked and hence picked up and installed the missing modules. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tar won't extract all files when a file with exe extension precedes the same without extension inside the archive
- 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 reverted so behaviour is once again predicatable and it doesnt break simple takess like extracting archive. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tar won't extract all files when a file with exe extension precedes the same without extension inside the archive
- 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, apparently its by design :( It causes us pain regularly so we would like this fairly recent change reverted so behaviour is once again predicatable and it doesnt break simple takess like extracting archive. Yes, yes. The pain. The pain. Danger Will Robinson! There really is not much point in rehashing this again under a different subject. If you or anyone would like to offer patches which change the behavior while keeping everyone happy about .exe handling please do so. Isn't the commit which changed the behaviour stored so where, as this has worked fine in the past, so in theory it could be just applied in reverse? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Inconsistence on file operation when the name already exists with exe extension
- 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 independently operate file while file.exe exists: copy file.exe file Now there are file and file.exe Nevertheless, FYI, powershell is not Cygwin and no one is saying that the behavior you're seeing is mandated by Windows. What you are seeing is a Cygwin accommodation for the fact that .exe is a special extension. Cygwin is not a new project. Its handling of .exe has been hashed and rehashed throughout the life of the project. The current behavior is the compromise that we've settled on. This is a change which causes us pain regularly. The defaults in previous cygwin versions worked well and where predicatable from both a coding and user perspective. So we would have to agree with the author here that the current behavour should be reviewed and reverted to the much safer and more expected defaults where by only execution is a special case nothing more. So, what you are seeing is expected. Continuing to argue without familiarizing yourself with past discussions is not likely to expose anything new. Take the example of a tar archive which has a windows .exe and say a Linux binary of the same name excluding the .exe. The current behaviour will have random results depending on the order of the files in the archive. So its likely that even though the archive extracted a working .exe file once the extract is actually complete the .exe will not be present. I appreciate that the idea was to make cygwin more internally consistent however surely predictable vs. random behaviour (as far as the user is concerned) is preferable is it not? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygrunsrv fails to prompt for user password
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 interactive session and incorrectly determining its not as in our case we are running the cygrunsrv via ssh e.g. ssh cygrunsrv We know that this worked correctly in cygrunsrv V1.34, Mar 18 2008. Bug introduced recently? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin getpass broken recently? was: cygrunsrv fails to prompt for user password
- 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 specified. It seems like cygrunsrv maybe checking for an interactive session and incorrectly determining its not as in our case we are running the cygrunsrv via ssh e.g. ssh cygrunsrv We know that this worked correctly in cygrunsrv V1.34, Mar 18 2008. Bug introduced recently? After inspecting the code for cygrunsrv and adding some debug I've determined this isn't a bug in the util but in cygwin's getpass function which I believe may have been changed recently by Corinna Vinschen, after googling around. Is this a new issue caused by these changes Corinna? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: socket performance (was Re: Building cygwin1.dll)
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 10, 2012 2:45 PM Subject: Re: socket performance (was Re: Building cygwin1.dll) On Jan 10 14:45, Johan van den Berg wrote: On 09 Jan 2012, at 3:43 PM, Corinna Vinschen wrote: How's the performance in your scenario when applying the below patch instead of yours? I have to run back with my tails between my legs. I implemented your patch, and the transfer speed on a 200ms latency, 10mbit max link went down to 5-6mbit using rsync. I then rolled back to my version, and suddenly also got 5-6mbit. I started another rsync and I was able to max the 10mbit line, hence, I think my original patch never had the effect I hoped for. Checking further, I noticed that stopping a task in windows task scheduler doesn't actually stop the rsync, so the only reason why I then must have seen that 10mbit max on my patch was simply because another rsync was already running ;( I am now however back to the drawing board. With your patch on both ends of the line, with a client rsync option of --sockopts=SO_SNDBUF=200,SO_RCVBUF=200 I still only get 5-6mbit max. I installed iperf on both ends, and no combination of settings (higher window size, higher MSS) will give me more than 5-6mbit transfer rate, except when I add the -P option which does parallel transfers. As soon as I do parallel, I can max the line. I then tested with a 100mbit link, and got similar results. Thinking outside the box, I started up iperf on a linux box on the other end of a 100mbit line: Cygwin to cygwin = 5mbit Cygwin to linux = 5mbit Linux to linux = 28mbit In all cases, adjusting the window size had no effect other than making the client think it can transfer faster if the buffer is bigger than the total amount of data to send. Any advice while I carry on trying to figure this out? What Windows versions are we talking about? Is that pre-Vista? XP, for instance? If so, setting the buffer size 64K should have no effect. I really don't know why the performance should be so much worse than under Linux in your scenario, sorry. Cygwin is not trying to do anything fancy. The speed should be basically in the same range as on Linux. At least it is for me when using sftp. When using scp I just found that I get a similar bad performance, only 6.9 MB/s instead of 35 MB/s. Is it possible that the limiting factor is not the socket, but the pipes between rsync and ssh, assuming you are using rsync over ssh? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: socket performance (was Re: Building cygwin1.dll)
- 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 that too, just in case you machine has got a degraded tcp stack. http://support.microsoft.com/kb/983528 I tried that, but it doesn't install. The installer tells me The update is not applicable to your computer. This is W7 64 bit on a Lenovo laptop. What's also puzzeling is this. I tried this on three virtual machines as well, W7 32, W7 64, 2008R2 64. In all three VMs scp was almost just as fast as sftp, about 13 MB/s. So why is scp (and rsync, too, btw) half as fast on the real HW as on the VMs while sftp is three times faster?!? That doesn't make sense. One of our guys had the same, when they tried to install the fix but when I downloaded it and tried on exactly the same machine without changing anything it just worked. I know it sounds silly but did you download the correct version on the 64bit machine? If this bug is effecting your you need to ensure that you make no connections using the machine that could possibly trigger the throughput issues prior to testing. Otherwise you'll be using a tcp stack without scaling. If you want me to mail you the exact download link I have from MS for this patch to check, let me know. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: socket performance (was Re: Building cygwin1.dll)
- 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 too so unless there's something else a play i.e. running as Administrator UAC rubish? If this bug is effecting your you need to ensure that you make no connections using the machine that could possibly trigger the throughput issues prior to testing. Otherwise you'll be using a tcp stack without scaling. Sounds tricky. The laptop is a domain member and it's not in the same room with me so I'm running this via rdesktop. But that would be fixable. However, if this issue is the problem, then why is sftp fast and only scp and rsync slow? I can reproduce this at will, not only once in the right order. Hmm that would indeed not be explained by the KB iirc there are some internal differences between the way sftp and scp transfer data. Do you have a wireshark dump of the two transfers we could examine? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
- 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 with Cygwin's git + Cygwin's ssh. My guess is that there is some kind of race condition in the pipe setup code when both ends of the pipe are Cygwin processes, but I'm admittedly unfamiliar with Cygwin's pipe code. Possibly the same issue which still plagues rsync under cygwin? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Strange fstatat / stat behavour on directories causing tar file changed as we read it error
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 said directory or its children. It seems that purely looking in a directory will change the size value reported by fstatat and likely stat. For a directory which hasn't been traversed / looked in its size is 0 where as after its been looked in it tends to report 8192. The result is that tar which checks for consistency of the data its archiving errors (although soft error) when archiving a directory as on initial access its size is 0 but after compressing all the files in said dir and hence looking in that directory its size is 8192. The attached patch fixes this strange behaviour by ignoring size changes for directories as well as correcting the file size check to also detect file shrinks as well as growths, which seemed very odd. Is there some meta data caching going on in cygwin or Windows which causes this very strange behaviour? Regards Steve tar-src-create.c.patch Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange fstatat / stat behavour on directories causing tar file changed as we read it error
- 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 be nicer to limit the workaround to just those file systems (and have st_size always return 0 for directories from those systems). FS was just NTFS, at first we thought it might be being caused by compression being enabled on the files / directories but we confirmed the behavour on an machine with uncompressed volumes as well. Is there some meta data caching going on in cygwin or Windows which causes this very strange behaviour? Giving us more details about your filesystem would help us answer that question. 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 drwxr-xr-x 1 test test8192 Oct 20 14:09 testdir uname -a CYGWIN_NT-6.0-WOW64 hern4 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin Running under Web Server 2008 Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange fstatat / stat behavour on directories causing tar file changed as we read it error
- 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 drwxr-xr-x 1 test test 8192 Oct 20 14:09 testdir uname -a CYGWIN_NT-6.0-WOW64 hern4 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin ^ Did you try with the current version of the cygwin package? I tried your test on W7 uses the 1.7.7 and had no problem. It would be interesting to know if what you're seeing is and old bug or possibly W2K8-specific. Unfortunately that's not easy as the machines are in production 24/7 and to upgrade would been to take them offline :( I'll try to get box installed with 1.7.7 for testing. We've not seen this before but it does seem to happen quite a lot with this particular directory structure we have which typically has 90K+ files in 5k+ directories in it, all of which are small, total size just 400MB Not 100% sure, but I believe we have had a Windows 7 exhibit the same behaviour. 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. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange fstatat / stat behavour on directories causing tar file changed as we read it error
- 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% clear the pattern I see is:- 1. ls -l gives some dirs in testdir as 0 size 2. Run: find testdir 3. ls -l reports all dirs in testdir as 8192 size 4. wait 30 seconds 5. ls -l reports all dirs in testdir as 8192 size 6. wait another minute or so 7. ls -l reports some dirs in testdir as 8192 size and some as 0 But of course I'm working in an empty directory. I'm also going to guess that you're mounting your directory with the 'noacl' option. If that's true, you might try removing that option to see if it makes any difference. From what I've seen it needs subdirs / files to cause the strangeness. Don't think we are using noacl at least mount doesn't show it:- C:/testdir on /usr/local/testdir type ntfs (binary) /etc/fstab shows:- c:/testdir /usr/local/testdir ntfs binary,auto 0 0 Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists
- 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 executables when the suffix is omitted, you are basically confusing cygwin by creating a directory and an executable with the same name. That said, there's probably room for improvement for recognizing the situation, and trying to be smarter when both directory and .exe executable exist; and the patch may need to be in coreutils rather than in cygwin1.dll (since cp is doing some extra legwork for .exe magic in the first place). Good thing I'm building coreutils 8.9 today :) -- In my case, I am using Winzip to make an executable Zip file that ends up having the same name as the directory. Every time I make a new version, I rename the directory as indicated. This used to work, possibly even in early Cygwin 1.7 Think of this as similar to having an installer file named packagename.sh. Linux wouldn't confuse the directory packagename and the executable packagename.sh I'd agree these latest fixes for handling .exe cause us problems constantly. I really don't understand this obsession for all the special handling when it used to work just fine as it was. In our case when we have Linux and windows files in an archive with the same name except the extension everything goes to pot, even tar fails to expand it which used to work without a problem :( Executable is a permission its not an extension so why treat a file with .exe extension any different with the exception of when looking for a binary to run, which is an understandable special case given the Windows environment. 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? If this was truly the goal and given Unix doesn't prevent Unix two executable binaries, one with no extension and one with an .exe extension coexisting then why should cygwin? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists
- 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? With the Unix look and feel, do you type 'ls file' or 'ls.exe file'? There would be a LOT of upset users if we didn't do at least some magic for .exe. It's an unfortunate problem of running on Windows, while still providing apps that can be invoked from non-cygwin processes (if we wanted, we could name cygwin binaries with no extension, just as in Unix, but then native windows apps couldn't easily run them). As acknowledged that's one of required special cases, but when I expand an archive with two files on Unix I end up with two files and not one as in the following on cygwin:- tar -xvzf cygwin-test.tar.gz w/ w/ls.exe w/ls [r...@blade01]/tmp: [r...@blade01]/tmp: ls -l w total 0 -rw-r--r--+ 1 root None 0 2011-01-04 20:42 ls So not only did I loose a file I lost the windows one, not exactly desired behavour. What's even more confusing for the user is that its order dependent so if the tar extracts w/ls followed by w/ls.exe instead of w/ls.exe followed by w/ls you do get both files. This always used to work just fine its only been broken in 1.7. When I raised this when we first identified the problem we where basically told that wasnt a valid use of cygwin so would not be fixed, so I expect this directory problem which stems from the same behavour will be the same as well :( With something like cygwin there are always going to be querks and gotyas but some of the recent fixes seem to taking a step backwards breaking otherwise fine uses of this most valuable tool. If anyone's interested in revisting this issue you'll find it under the subject: tar deletes .exe files on extraction in the archives. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
tar fails to expand simple tar.gz across junction point
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 tar fails with:- tar -xvzf /tmp/test.tar.gz dir2/subdir1/file1 tar: dir2/subdir1/file: Cannot open: No such file or directory looking in dir2 subdir1 wasnt created. If we change into c:\dir1\dir2 and retry extract all works well so there seems to be an issue when the extracting path straddles the reparse point uname -a CYGWIN_NT-6.1-WOW64 blade33 1.7.0(0.212/5/3) 2009-09-11 01:25 i686 Cygwin Known issue? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.7: rm -rf sometimes fails - race condition?
- 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 syscall and allows it to return before completion. I don't think we want to modify Cygwin to not trust success return values from system calls. Is this the age old delete on close raising its ugly head again? So the rm kicks in a file is shared locked, rm uses the cygwin unlink code which schedules the file for deletion and returns success without actually succeeding, hence when it comes to delete the parent dir it fails as the file actually still exists. Finally figured this is the cause of unlink in perl returning success when the file still existed, I was like WTF!! A shared resource file locked by another process in our case, and this behaviour lead to many hours of head scratching and large amounts of workaround code. Personally I think the only solution is to remove this delete on close code and fail hard for shared locked files, as it gives a much more predictable code flow. Having unlink return success but the file not being deleted before return is confusing as hell :( Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
- 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 somethng is a typical use of cygwin. No, it really isn't. I'd beg to differ; I'd suggest it is, as suggested by the OP, actually quite a common use. You only have to look at the use of say perl and you will have users quite regularly compiling their own DLL's as they install modules via CPAN, and this is quite painful due to all the issues it can present with rebase. While I love cygwin, I must say that its supporting community can be very dismissive of its users to the point of alienating potential contributors. I myself has have experienced this on several occasions and have ended up finding myself not raising issues that affect us daily for fear of being shot down for no more reason that someone doesn't think its import to fix or should work that way anyway or even doesn't like the way you structured you post. To reiterate I still think that developers deserve much respect and thanks for all the effort they put in, but a little more open mindedness and approachability like that which can be found in other open source communities such as SFU and FreeBSD wouldn't go a miss sometimes ;-) Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.1: Mintty/bash window start: -bash: regtool: command not found
- 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 cygcheck unless as Dave asks there is some other flag which may identify this problem? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin, perl or DBI seriously broken in 1.7.1?
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 issue in perl 5.10. Thought I'd switch back to 5.8 but that's not available by the setup.exe any more so I'm a bit stuck. Anyway the details are: use DBI; use Data::Dumper; // Setup db connection... my $sql = SELECT 214, 16, 150, 15, 55000, 5120, 5, 25769803776 FROM dual; my $sth = $dbh-prepare( $sql ); $sth-execute or die failed to execute; my @array = $sth-fetchrow_array; print Dumper( \...@array ); Now assuming no errors @array should contain 8 items but it doesn't instead I randomly get just the last value: $VAR1 = [ '25769803776' ]; or the correct value: $VAR1 = [ '214', '16', '150', '15', '55000', '5120', '5', '25769803776' ]; So what on earth is going on? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin, perl or DBI seriously broken in 1.7.1?
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 for sure though 5.10.1-2 is not reliable here. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Nasty permissions / pathing bug in perl on 1.7
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 li...@multiplay.co.uk To: cygwin@cygwin.com Sent: Tuesday, December 01, 2009 5:06 PM Subject: RE: Nasty permissions / pathing bug in perl on 1.7 Hi, After testing this with a latest version of perl (5.10.1-1) / cygwin (1.7), we still see: [r...@quad32]~: perl --version This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int (with 12 registered patches, see perl -V for more detail) Copyright 1987-2009, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. [r...@quad32]~: ./tmp-test.pl -rw-r--r--+ 1 root None 0 2009-12-01 17:01 /tmp/test.exe cygwin warning: MS-DOS style path detected: C:/cygwin/tmp/test.exe Preferred POSIX equivalent is: /tmp/test.exe CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames -rw-r--r--+ 1 root None 0 2009-12-01 17:01 /tmp/test.exe -rwxrwxrwx+ 1 root None 0 2009-12-01 17:01 /tmp/test.exe [r...@quad32]~: uname -a CYGWIN_NT-6.1-WOW64 quad32 1.7.0(0.218/5/3) 2009-11-27 15:38 i686 Cygwin [r...@quad32]~: The tmp-test.pl is the same as the one in Steve's email. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Nasty permissions / pathing bug on 1.7
- 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 behind this change? 2. Surely when performing changes on permissions with a mount mode of noacl it should be a fatal error? #2 I think is imperative as to leave the user thinking all is well is going to lead to real confusion, just like it did here, especially as this worked just fine in 1.5. I know the warning is there but at no point does it mention the fact it totally breaks anything that tries to manipulate permissions. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Nasty permissions / pathing bug on 1.7
- 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 best and dangerous to the user at worst. A simple example is that process creation using the Win32 perl module under cygwin taking win32 paths fails when the execute permission set on the target binary is not set. This is the case which highlighted the problem to us. There was a thread on this list about this very problem a couple of months ago. It was generally agreed that handling Win32 paths this way consistently is a good thing. I would like to challenge this, as its unituitve, undocumented ( as far as I can see ) and very confusing for the user see above and below. 2. Surely when performing changes on permissions with a mount mode of noacl it should be a fatal error? No. noacl means that permissions are faked. It's easy. If you want POSIX permssion handling, stick to the POSIX world. That's easy to say but surely the entire goal of cygwin is to ease the interaction of Windows and POSIX functionality is it not? While I appreciate change is often required to make progress, it seems quite clear that this change in behaviour in its current state is very much a disaster waiting to happen or some users. Why do I say that? Well first off from our experience this was an nightmare to track down, taking several days to identify the source of this quite random behaviour. Now if your think about the number of scripts, binaries etc which may also be broken by this change but not know about it; surely that's not something you want to inflict on the cygwin user base is it? To be clear, my objection to this is not that it's been changed, although IMO doing so to be consistent doesn't seem like a very compelling reason given other aspects don't abide by the same rules; its that the change silently breaks things! Surely no one thinks that's an expectable state of play do they? To conclude, we've already changed our code in this particular example to workaround this issue and we're aware of it for the future, but how many others are going to get burnt and waste significant amounts of time tracking down issues created by this change if it remains in its current state? Given this I would respectfully like to propose either:- 1. Warn but preferably error when performing set permission operations on noacl mount points. 2. Revert so that Win32 paths aren't mounted with noacl. #1 with an error would be my personal preference. It would have allowed us to identify and correct this issue in seconds instead of the days it actually took. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Nasty permissions / pathing bug in perl on 1.7
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:
[script]
#!/usr/bin/perl -w
use strict;
unlink '/tmp/test.exe';
print `touch /tmp/test.exe; ls -l /tmp/test.exe`;
if ( ! chmod 0777, 'C:/cygwin/tmp/test.exe' )
{
print STDERR Failed to chmod ($!)\n;
exit 1;
}
print `ls -l /tmp/test.exe`;
if ( ! chmod 0777, '/tmp/test.exe' )
{
print STDERR Failed to chmod ($!)\n;
exit 1;
}
print `ls -l /tmp/test.exe`;
[/script]
The output of this here is:
./t.pl
-rw-r--r-- 1 root None 0 Nov 29 18:41 /tmp/test.exe
-rw-r--r-- 1 root None 0 Nov 29 18:41 /tmp/test.exe
-rwxrwxrwx 1 root None 0 Nov 29 18:41 /tmp/test.exe
As you can see after the first chmod using a dos like path no error is
generated but the operation silently fails.
This is using 1.7 from about a month back, so would be good if someone with
a current version could test to see if this is still an issue as its very
nasty imo.
CYGWIN_NT-6.1-WOW64 blade23 1.7.0(0.212/5/3) 2009-09-11 01:25 i686 Cygwin
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync pull problem and possible solution
- 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 you using it in daemon mode or over ssh, over ssh is dodgy as hell here :( Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl errors after a while on windows 7 / 2k8 r2
- 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 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 Cygwin Anyone seen this issue before, or have any clue on how to debug it? Sounds like BLODA. http://cygwin.com/acronyms#BLODA There's no reason that a CreatePipe() should fail with a Invalid Function error. Unfortunately not as the machines have a clean install of Windows 7 in, with things like Windows Defender Service disabled. Could this be a resource issue as we are running quite a few cygwin processes on these machines. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl errors after a while on windows 7 / 2k8 r2
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 Cygwin Anyone seen this issue before, or have any clue on how to debug it? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tar deletes .exe files on extraction
- 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 mydir/myexe.exe mydir/myexe ls myddir myexe Yeah, that's to be expected. Cygwin always handled the .exe suffix transparently in terms of stat(2) calls, but Cygwin 1.7 also handles them transparently in terms of open(2) and any other call. Therefore, if a file foo.exe exists, and an application calls stat(foo), it will get told that, yes, foo exists. That's a basic component of being able to call foo.exe from bash by just typing fooenter. POSIX systems just don't have the .exe suffix for executables. AFAICS from the strace, tar unpacks mydir/myexe.exe, then it goes ahead to unpack mydir/myexe. It tries to open the file with O_CREAT | O_EXCL flags. Since the file exists from Cygwin's POV, open(2) returns -1 with errno set to EEXIST. If that happens tar calls unlink(mydir/myexe) and the unlink() call succeeds, since, as mentioned above, the .exe suffix is transparent to every filesystem call. Therefore, unlink(mydir/myexe) actually deletes mydir/myexe.exe. Then tar proceeds to unpack mydir/myexe. Keep in mind that myexe and myexe.exe are for all practical purposes the same file from Cygwin's point of view. On a POSIX system you just don't have a normal file called myexe in the same directory as an executable myexe, since that is the same file anyway, and the .exe suffix is just an annoying Windowism. On Cygwin, you should avoid having a file foo and a file foo.exe in the same directory at all cost to avoid puzzeling POSIX borderline behaviour like this. What you do is essentially in the not supported class of problems. Fortunately for you there's a workaround. If the order of the files in the tar archive is reversed, both files are unpacked. Or, unpack mydir/myexe.exe explicitely afterwards. The reason that this works is that Cygwin does not check for a file foo, if the name of the file is explicitely given as foo.exe. Thanks for the confirmation there Corinna however I do think this is quite an issue and it likely catch people out. In this example the result was nothing worked as the myexe is a none native binary only myexe.exe is a windows exe, but I wouldnt be surprised if there are cases where you have and exe and a data file with the name the same just the app with the .exe with the extension. It might be a silly idea but would it potentially be an option to alter this behaviour based on an cygwin environment variable, so that the past behaviour is restored for wider compatibility. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
tar deletes .exe files on extraction
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 mydir/myexe.exe ls myddir myexe.exe rm -rf mydir; tar -xvzf test.tar.gz; mydir/myexe mydir/myexe ls myddir myexe This happens with:- tar (GNU tar) 1.22 CYGWIN_NT-6.1-WOW64 blade14 1.7.0(0.212/5/3) 2009-07-24 09:59 i686 Cygwin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.5.25: rsync hangs
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 dathe...@gmail.com
To: cygwin@cygwin.com
Sent: Sunday, August 02, 2009 4:12 AM
Subject: 1.5.25: rsync hangs
rsync frequently hangs on me in some socket call - this is after i
have used it before in
the current session usually. it is not repeatable on demand - it just
sometimes gets into
this state.
here is the strace output:
85 679411 [select_socket] rsync 3588 thread_socket: write_ready
14494 680328 [sig] rsync 1844 wait_sig: signalling pack.wakeup 0x654
502 680830 [main] rsync 1844 sig_send: returning 0x0 from sending signal -34
65 680895 [main] rsync 1844 writev: writev (4, 0x22B610, 1)
2464 683359 [main] rsync 1844 writev: 4 = write (4, 0x22B610, 1), errno 0
82 683441 [main] rsync 1844 cygwin_select: 6, 0x22A3E0, 0x22A3D8,
0x0, 0x22A3D0
66 683507 [main] rsync 1844 dtable::select_read: fd 5
32 683539 [main] rsync 1844 cygwin_select: to-tv_sec 60,
to-tv_usec 0, ms 6
32 683571 [main] rsync 1844 cygwin_select: sel.always_ready 0
4230 683641 [main] rsync 3588 select_stuff::wait: m 2, ms 6
40 683681 [main] rsync 3588 select_stuff::wait: woke up. wait_ret
1. verifying
33 683714 [main] rsync 3588 select_stuff::wait: gotone 1
31 683745 [main] rsync 3588 select_stuff::wait: returning 0
31 683776 [main] rsync 3588 select_stuff::cleanup: calling cleanup routines
444 684015 [main] rsync 1844 start_thread_socket: Handle 0x688
35 684050 [main] rsync 1844 start_thread_socket: Added to readfds
32 684082 [main] rsync 1844 start_thread_socket: exitsock 0x6B8
32 684114 [main] rsync 1844 start_thread_socket: stuff_start 0x22A344
1226 685002 [main] rsync 3588 socket_cleanup: si 0x10012A98
si-thread 0x61106F30
119 685121 [main] rsync 3588 socket_cleanup: sent a byte to
exitsock 0x7F0, res -1
64 685185 [main] rsync 3588 socket_cleanup: reading a byte from
exitsock 0x7F0
1201 685315 [main] rsync 1844 select_stuff::wait: m 2, ms 6
407 685722 [select_socket] rsync 1844 thread_socket: stuff_start 0x10015B04
can't recall if it hangs with just simple flags -avx (note, no ssh
involved, just local copy),
but it for sure does when i use these:
RSYNC_MAX_DELETE=${RSYNC_MAX_DELETE:-500}
RSYNC_MODIFY_WINDOW=${RSYNC_MODIFY_WINDOW:-10}
set -x
rsync \
--archive \
--verbose \
--one-file-system \
--delete-before \
--max-delete=$RSYNC_MAX_DELETE \
--itemize-changes \
--human-readable \
--progress \
--modify-window=$RSYNC_MODIFY_WINDOW \
--exclude=System Volume Information \
--exclude=Recycled \
--exclude=lost+found \
--exclude=RECYCLER \
--exclude='*DONOTDELETE*' \
$source $target
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.5.25: rsync hangs
- 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 joy. Alternatively try sfu's version which apart from the 2GB file limit works well. there's no ssh involved in my scenario i wonder if 1.7 has this same problem, i'm using i guess a much older version of 1.5 or maybe even earlier on my other computer and do not have the issue (that release contains rsync 2.x vs the 3.x in this one causing issues) So your using rsync in daemon mode then? As otherwise it will default to using ssh unless you have a very old version using rsh, so you may be using it without realising? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.5.25: rsync hangs
- 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 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs can't start-process more than 30~40 processes
- 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 have debugged it again, and I think I have more clue. I have read the how-cygheap-works.txt, and this might be a known problem. [...] it is a small number then something is wrong and we're allocating too much of the cygheap. The cygheap was always supposed to be relatively small. Maybe we're abusing it too much in 1.7. There are quite some fds. In start-process, emacs will allocate 1 PTY and 1 pipe for each process it starts. Yes, I assumed that there were a bunch of fds but I was looking for an exact number rather than quite some. I can't give exact details about how to find the number now but I thought that since you were looking at the code it wouldn't be too hard to figure this value out. Anyway, Corinna has a stopgap fix for this which will probably show up in a 1.7.0-* release sometime soon. The stopgap fix is in 1.7.0-53. Ahh this might also be the cause of the issue we where seeing when I started the thread:- maximum number of cygwin processes per user? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Invalid csih method in ssh-user-config scripts
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: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
SOLVED: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
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: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
rebase issues when installing perl modules on 1.7
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 09:59 i686 Cygwin The rebase command I use atm is: ash -c find /usr/lib/perl5 -name \*.dll -print0 |xargs -0 chmod a+wrx; /bin/rebaseall Example errors: Checksum for /home/Administrator/.cpan/sources/authors/id/T/TJ/TJENNESS/File-Temp-0.22.tar.gz ok 12 [main] perl 13004 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl5\5.10\i686-cygwin\auto\Cw \Cwd.dll to same address as parent: 0x5227 != 0x6498 4 [main] perl 14088 fork: child 13004 - died waiting for dll loading, errno 11 099884 [main] perl 10356 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl5\5.10\i686-cygwin\auto\Cw \Cwd.dll to same address as parent: 0x5227 != 0x6498 113903 [main] perl 14088 fork: child 10356 - died waiting for dll loading, errno 11 Checksum for /home/Administrator/.cpan/sources/authors/id/A/AD/ADAMK/File-HomeDir-0.86.tar.gz ok 2 [main] perl 9032 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl5\5.10\i686-cygwin\auto\MIM E\Base64\Base64.dll to same address as parent: 0x6D6B != 0x6DD7 4 [main] perl 3552 fork: child 9032 - died waiting for dll loading, errno 11 ash -c find /usr/lib/perl5 -name \*.dll -print0 |xargs -0 chmod a+wrx; /bin/rebaseall Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-52
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 corinna-cyg...@cygwin.com I just uploaded a new Cygwin 1.7 test release, 1.7.0-52. As it turns out, there are still two problems to fix(*) and our vacation schedule is so that we won't get to fix both of them in time *and* release 1.7.1 next week. So, here's 1.7.0-52, which is yet again supposed to be the last test release. Which is to say, there will be definitely not more than one more test release. I mean it. ... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
maximum number of cygwin processes per user?
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 user by user basis as starting the same thing under a different user seems to work. Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: maximum number of cygwin processes per user?
- 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 what you mean by per program? I'm still trying to determine an error message, I see the new process being created but it never gets to the first print. This is a perl thing again so I'm wondering if there are more issues in addition to the SEH one being discussed in the other thread. One thing I have seen even with this compile of perl with threads disabled is a process fork where the created process almost instantly take 2GB. The forking process then seem to timeout the creation and fork again and again... Using all memory and cpu in the process over an extended period of time. Unfortunately I've not managed to identify a real test case for this as it seems to happen most frequently when installing new perl modules via CPAN. Also noticed that on 2008 64bit, rebase issues are VERY common, something I've not experienced on XP. I wonder if this has something to do with what's described as Address Space Load Randomization in process explorer? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: maximum number of cygwin processes per user?
- 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh-host-config now involves cygwin-service-installation-helper.sh
- 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 google bots to be very attentative so you won't be bothered that much by dumb people like me in future. C'mon this is open source project, while yes it would be nice to have everything work out the box, the tools are there and as a sysadmin you can make things like this work. Once the issues are identified I'm sure any patch you create that improves the scripts behaviour to edge cases would be greatly appreciated. Personally I was most surprised with the new 1.7 scripts, a great improvement for which I thank those involved as it installed first time out the box for me :) If you don't have the skills required to do the work required, there are ports of calls but you will likely have to show some recompense for their efforts, which isn't much to ask is it? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- 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 invoked. Of note when running 1.5.25 I did get the windows application error dialog, but with 1.7 and the latest snapshot it doesn't, so maybe using 1.5.25 might help? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How to activate new fstab mount points under 1.7?
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 obviously not ideal. Any I missing something or has this functionality just been overlooked? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- 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 unconditional breakpoint there and let it run until I hit it: From my experience last night you should be able to use something like:- b 113 if ( 0 == (**(verifyable_object **)objectptr) If not here at least it hits that break ~ 280 times before blowing up so setting a conditional on that occurrence should help. Unfortunately I'm currently testing a none threaded compile on the machine so cant check myself just now. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to activate new fstab mount points under 1.7?
- 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: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl 5.10 threads on 1.5.25 = instant crash
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 $thrd = threads-create( \dothread );
$thrd-join();
print STDERR Testing done\n;
sub dothread { print STDERR I'm a thread!\n }
[/test]
Environment details:
$ uname -a
CYGWIN_NT-6.1-WOW64 ibm 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0 patch 34065) configurati
on:
Platform:
osname=cygwin, osvers=1.5.25(0.15642), archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 reini 1.5.25(0.15642) 2008-06-12 19:34 i686 cygwin '
config_args='-de -Dmksymlinks -Dusethreads -Dmad=y -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=undef, uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-ali
asing -pipe -I/usr/local/include',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pip
e -I/usr/local/include'
ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lsee
ksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,-
-stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat
perllibs=-ldl -lcrypt
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import -Wl,--export-
all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY MYMALLOC PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MAD PERL_MALLOC_WRAP
PERL_USE_SAFE_PUTENV USE_64_BIT_INT USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
Locally applied patches:
MAINT34065
CYG11 no-bs
CYG12 no archlib in otherlibdirs
CYG14 Dynaloader
CYG15 static-Win32CORE
Bug#55162 File::Spec::case_tolerant performance
Built under cygwin
Compiled at Jun 30 2008 16:05:15
%ENV:
CYGWIN=
@INC:
/usr/lib/perl5/5.10/i686-cygwin
/usr/lib/perl5/5.10
/usr/lib/perl5/site_perl/5.10/i686-cygwin
/usr/lib/perl5/site_perl/5.10
/usr/lib/perl5/vendor_perl/5.10/i686-cygwin
/usr/lib/perl5/vendor_perl/5.10
/usr/lib/perl5/vendor_perl/5.10
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.
[/quote]
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl 5.10 threads on 1.5.25 = instant crash
Also happens on 5.8.8 :(
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=cygwin, osvers=1.5.24(0.15642), archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 reini 1.5.24(0.15642) 2007-01-31 10:57 i686 cygwin '
config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads -Uusemymalloc
-Doptimize=-O3 -Dman3ext=3pm -Dusesitecustomize -Dusedev
l'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe
-Wdeclaration-after-statement',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe
-Wdeclaration-after-statement'
ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using dmd
0.125)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat
perllibs=-ldl -lcrypt -lgdbm_compat
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_REENTRANT_API USE_SITECUSTOMIZE
Locally applied patches:
CYG01 - hints.cygwin.sh ldflags -s
CYG02 - lib-ExtUtils-Embed insensitive against leading \s
CYG03 - lib-Test-Harness-Straps $ENV{PERL5LIB} = ''
CYG04 - major.version.cygwin.sh cygperl-5_8.dll and not cygperl-5_8_x.dll
CYG05 - add Win32CORE to core
CYG07 - File-Spec-Cygwin-TMPDIR.patch
Bug#38628 - allow legacy Cwd-cwd()
Bug#40103 - File-Spec-case_tolerant.patch from 5.9.5
Built under cygwin
Compiled at Jul 8 2007 19:12:08
%ENV:
CYGWIN=
@INC:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/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 threads on 1.5.25 = instant crash
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 $thrd = threads-create( \dothread );
$thrd-join();
print STDERR Testing done\n;
sub dothread { print STDERR I'm a thread!\n }
[/test]
Environment details:
$ uname -a
CYGWIN_NT-6.1-WOW64 ibm 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0 patch 34065) configurati
on:
Platform:
osname=cygwin, osvers=1.5.25(0.15642), archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 reini 1.5.25(0.15642) 2008-06-12 19:34 i686 cygwin '
config_args='-de -Dmksymlinks -Dusethreads -Dmad=y -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=undef, uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-ali
asing -pipe -I/usr/local/include',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pip
e -I/usr/local/include'
ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lsee
ksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,-
-stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm
Re: perl 5.10 threads on 1.5.25 = instant crash
- 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: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl 5.10 threads on 1.5.25 = instant crash
- 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]
WFM with perl 5.10.0 on both 1.5 and 1.7.
Thanks Dave, maybe a Windows Server 2008 R2 64bit issue?
FYI, 1.5.25 is rumored to have problems on Windows Server 2008 64bit.
At the very least, it is known to have inexplicable hangs not seen
in 1.7.
... and the script works fine on Windows 7 Build 7201 running under
Cygwin 1.7.
Thanks guys looks like an update to 1.7 is in order then, any tips
or gotchas I should be aware of?
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- 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 18GB RAM showing 16 cores if that may be of interest. gdb is not much help, so not sure what to try next? [log] Starting program: /usr/bin/perl threads.pl [New thread 560.0x734] Error: dll starting at 0x778e not found. Error: dll starting at 0x76c7 not found. Error: dll starting at 0x778e not found. Error: dll starting at 0x777e not found. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 560.0xdc] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Testing threads... Program exited with code 0305. (gdb) [/log] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- 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 not much help, so not sure what to try next? 1) rebaseall 2) http://cygwin.com/problems.html already tried rebaseall just case unfortunately. Reinstalled 1.5.25 with just defaults + perl 5.10, ran rebaseall, confirmed still fails. cygcheck.out attached. Threw c++ debugger at it and it errors in the main cygwin dll so it seems like its something deep in the bowls:( If there's anything else I can do here let me know. Going off now to dig for instructions on compiling cygwin with debugging symbols so I can try find you more info on the problem. Regards Steve cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
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 it exits:
[gdb]
Breakpoint 1, pthread_setspecific (key=0x19e9e88, value=0x19e9768)
at /netrel/src/cygwin-snapshot-20090711-1/winsup/cygwin/thread.cc:113
113 if ((*object)-magic != magic)
(gdb)
307 ~myfault () __attribute__ ((always_inline)) { _my_tls.reset_fault
(sebastian); }
(gdb)
285 andreas._myfault = old_j._myfault;
(gdb)
307 ~myfault () __attribute__ ((always_inline)) { _my_tls.reset_fault
(sebastian); }
(gdb)
285 andreas._myfault = old_j._myfault;
(gdb)
286 andreas._myfault_errno = old_j._myfault_errno;
(gdb)
209 int set (const void *value) {TlsSetValue (tls_index, (void *) value);
return 0;}
(gdb)
2259}
(gdb)
0x610b3108 in _sigbe () from /usr/bin/cygwin1.dll
(gdb)
Single stepping until exit from function _sigbe,
which has no line number information.
0x6ce32ea3 in XS_threads_create () from
/usr/lib/perl5/5.10/i686-cygwin/auto/threads/threads.dll
(gdb)
Single stepping until exit from function XS_threads_create,
which has no line number information.
Program exited with code 0305.
[/gdb]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- Original Message - From: Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com To: cygwin@cygwin.com Sent: Wednesday, July 15, 2009 1:03 AM Subject: Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash ) On Wed, Jul 15, 2009 at 12:36: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 cygwin exceptions. Was just trying to get a hint of the area of the problem since gdb doesn't actually break when it happens this seemed to be the only way to get that info. Any pointers on how I can help narrow down the issue? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync 3.0.4 over ssh hanging on cygwin 1.7
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 support 32bit files so less than 2GB. Regards Steve - Original Message - From: Fred Kemp [EMAIL PROTECTED] Good afternoon all, Please excuse my cygwin newbie status if I have missed something obvious. Having resolved the overly long file name issue with rsync in cygwin 1.5 by upgrading to version 1.7, I have hit a new problem, namely rsync hanging midway through transfer. No errors are reported or logged, nothing seems to be timing out, it just sits there indefinitely. Re-running rsync will maybe do a couple more files then hang again, and again, and again... Having read around tinternet, it seems I am not completely alone in this problem, but I have yet to find a solution that works for me. Briefly: I have set up ssh-keyless authentication between my server (OsX 10.5.5, rsync 3.0.4, OpenSSH 5.1p1) and a dozen or so PC's running XPsp2 (cygwin 1.7, rsync 3.0.4, OpenSSH 5.1p1) and use rsync to mirror user directories on the PC's to my server, as follows: rsync --verbose --progress --stats --rsh=/usr/bin/ssh --archive \ [EMAIL PROTECTED]:/cygdrive/c/Documents\ and\ Settings/ userdirectory/ /Users/userdirectory/ This is in effect identical to the method I use to mirror data between two OsX servers, where it can happily handle several terabytes of data and millions of files. I have tried rsyncing individual subdirectories in a userdirectory and that works fine but still it hangs when the whole directory is tried again. Similarly, one or two of the smaller user directories (around 15,000 files and 35Gb data) work fine. Over around 30,000 files seems to be where I have the problem... What is really strange is that if I run the rsync from the client PC to the server, it works fine, and subsequent rsyncs from the server also work fine (presumably since hardly any files have changed)... At this stage I am somewhat stumped and would appreciate any pointers the gurus can give, even as to whether this is believed to be an rsync, sshd or underlying cywin issue... Very happy to provide further info as required, or to be shot down in flames should I have done something stupid! ;-) Thanks in advance, Fred. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
inet_pton returns 1 on error
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: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 be where my problem lies. No, it hasn't changed but there might be a problem in the seteuid() function when running on 2008. I'll investigate. When you login through ssh, are you using password or pubkey auth? Pubkey auth, if there's anything I can do to help please let me know. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 problem seems to be UAC. Cygwin 1.5.25 is using impersonation tokens quite heavily. Due to this problem I dropped all the forced impersonation token usage from 1.7, so the issue will be fixed in Cygwin 1.7 as far as I can see from my tests. The only thing you might try is to switch off UAC entirely on that system and try again. I'm not sure if that helps since I can't test this right now. If you could try and report back? Tested this and there's no change, still get permission denied from chown via ssh. 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 know. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 know. This seems to work fine, is there anything I should be aware of if we looked to use this in production environment? One thing I did notice is that rebaseall fails with:- /usr/bin/cyglsa64.dll: fixing bad relocations FixImage (/usr/bin/cyglsa64.dll) failed with last error = 13 As a temporary workaround I renamed it to allow rebase to complete on all but this file. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 also a couple of changes which we don't exactly consider ready for release. In theory, you shouldn't use it in a production environment yet. Ooo thats a nice change :) I'd obviously like to avoid it but someones got to be first and if there is no way to fix chmod under 1.5.X it may be our only option. With this in mind I'll look to prep a full install and do some more in depth testing in order to determine if there are any show stoppers that would preclude us using 1.7. One thing I did notice is that rebaseall fails with:- /usr/bin/cyglsa64.dll: fixing bad relocations FixImage (/usr/bin/cyglsa64.dll) failed with last error = 13 As a temporary workaround I renamed it to allow rebase to complete on all but this file. The DLL has been build with VC++ due to the lack of a 64 bit capable gcc for Cygwin. As long as this is the case, rebaseall will have to be changed to skip cyglsa.dll and cyglsa64.dll. For the time being, what you did is the right thing to do. Hmm cyglsa.dll appeared to process fine could this cause an issue? Btw., another workaround using Cygwin 1.5.25 would be to use password authentication, at least as long as you're not logging in to a domain admin account. The latter requires tweaking /etc/group... Unfortunately password based access it not an option here for a number of reasons, mainly as its used by a large number of automation scripts remotely. 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 Thanks for taking the time to look at this, most appreciated. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 I have to do and I'm also not keen on debugging a monster like apache. No problem, good to confirm that its not a known issue if nothing else. I'll dig out the source code and look at tracking it down, its definitely something related to localhost binding so hopefully shouldn't be too hard to track down. Thanks again for the help. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 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. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 logs - both because you were sending email with a disclaimer. The last one was July 3. 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. That was before I had IT remove it explicitly for cygwin, would you like me to dig out the spam report? Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: valid messages refused as spam ( was: chmod permission denied on windows 2008 )
- 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 mail server reporting the message failed to send. I've included a snip from the message as it may be helpful to diagnose the issues, but is seems like the spam filter software is simply getting things wrong. We've had that in the past here due to Bayesian learning and the only solution was to flush the previous learned data. [refused] Thu 2008-07-03 23:01:32: -- RCPT To:cygwin@cygwin.com Thu 2008-07-03 23:01:32: -- 250 cygwin@cygwin.com, recipient ok Thu 2008-07-03 23:01:32: -- DATA Thu 2008-07-03 23:01:32: -- 354 go ahead Thu 2008-07-03 23:01:32: Sending xx\pd35001664007.msg to [209.132.176.174] Thu 2008-07-03 23:01:33: Transfer Complete Thu 2008-07-03 23:02:04: -- 552 spam score exceeded threshold Thu 2008-07-03 23:02:04: -- QUIT [/refused] Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 for the backup and restore rights both fail with ERROR_NOT_ALL_ASSIGNED. The problem is that there's no indication why it fails. Per MSDN this should only happen if the privilege is not in the token. Bottom line is, there's nothing Cygwin can do about this. Did you look into the security event long? Maybe there's a hint why this fails. You thought that was weird I just logged onto the box to test and look in the security event log and it just started working. No changes that I can find have been made, it was even the same cygwin prompt from the previous tests. If I find out what caused the change I will report back as I have another identical machine left to install. Very strange, most appreciate your help on this. Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 for the backup and restore rights both fail with ERROR_NOT_ALL_ASSIGNED. The problem is that there's no indication why it fails. Per MSDN this should only happen if the privilege is not in the token. Bottom line is, there's nothing Cygwin can do about this. Did you look into the security event long? Maybe there's a hint why this fails. You thought that was weird I just logged onto the box to test and look in the security event log and it just started working. No changes that I can find have been made, it was even the same cygwin prompt from the previous tests. If I find out what caused the change I will report back as I have another identical machine left to install. Very strange, most appreciate your help on this. Sorry seems I missed one critical element here. I thought I was doing all the tests under a cygwin prompt but in fact the chown's I was doing under an ssh'ed prompt. It works under a cygwin prompt on the desktop but fails when I'm ssh'ed in. So this actually looks like it may be a problem with ssh under 2008? 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 be where my problem lies. Regards Steve Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\Administratorwhich whoami /cygdrive/c/Windows/system32/whoami C:\Users\Administratorwhoami /all USER INFORMATION User NameSID blade0\administrator S-1-5-21-1034854827-3221323542-428946914-500 GROUP INFORMATION - Group NameType SID Attributes = === Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group BUILTIN\AdministratorsAliasS-1-5-32-544 Mandatory group, Enabled by default, Enabled group, Group owner BUILTIN\Users AliasS-1-5-32-545 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\REMOTE INTERACTIVE LOGON Well-known group S-1-5-14 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\This OrganizationWell-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group Mandatory Label\High Mandatory Level Unknown SID type S-1-16-12288 Mandatory group, Enabled by default, Enabled group PRIVILEGES INFORMATION -- Privilege Name Description State === = SeIncreaseQuotaPrivilegeAdjust memory quotas for a process Disabled SeSecurityPrivilege Manage auditing and security log Disabled SeTakeOwnershipPrivilegeTake ownership of files or other objects Disabled SeLoadDriverPrivilege Load and unload device drivers Disabled SeSystemProfilePrivilegeProfile system performance Disabled SeSystemtimePrivilege Change the system time Disabled SeProfileSingleProcessPrivilege Profile single process Disabled SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled SeCreatePagefilePrivilege Create a pagefile Disabled SeBackupPrivilege Back up files and directories Disabled SeRestorePrivilege Restore files and directories Disabled SeShutdownPrivilege Shut down the system Disabled SeDebugPrivilegeDebug programs Disabled SeSystemEnvironmentPrivilegeModify firmware environment values Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeRemoteShutdownPrivilege
apache crashing on windows 2008 when listening on localhost
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 crashing, I need to do more tests to confirm its actually functioning. This exact config runs fine under XP, 2003, 2003 R2 including 64bit but under 2008 x64 its not a happy bunny. The event log seems to indicate this is a crash in the main cygwin dll so I was wondering if anyone had seen anything like this and knew a fix? [crash] Faulting application httpd.exe, version 0.0.0.0, time stamp 0x432aedd4, faulting module cygwin1.dll, version 1005.25.0.0, time stamp 0x48515e73, exception code 0xc005, fault offset 0x000b3f59, process id 0xba4, application start time 0x01c8dc98373a8e9b. [/crash] I see there was some updates for 2008 in 1.5.25-11 so I updated just to be sure just now but no changes. Just in case its relevant as I know it does change the way netcards are addressed I do have HyperV install on this machine as well. Any ideas? Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
chmod permission denied on windows 2008
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 `test': Permission denied [EMAIL PROTECTED]/tmp: ls -l test -rw-r--r-- 1 root None 0 Jul 3 13:15 test [EMAIL PROTECTED]/tmp: [EMAIL PROTECTED]/tmp: grep testuser /etc/passwd testuser:unused_by_nt/2000/xp:1002:513:Test User,U-BLADE0\testuser,S-1-5-21-1034854827-3221323542-428946914-1002:/usr/home/testuser:/bin/bash [EMAIL PROTECTED]/: grep testuser /etc/group testuser:S-1-5-32-545:545: [EMAIL PROTECTED]/: ls -l |grep tmp drwxrwxrwt+ 3 Administrators None 4096 Jul 3 13:22 tmp All this works fine on XP and 2003 but is there something silly I'm missing for 2008? Regards Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 correct but this is appears to be the default as I'm not aware of any changes I've made in this area Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\Administratorwhoami /all USER INFORMATION User NameSID blade0\administrator S-1-5-21-1034854827-3221323542-428946914-500 GROUP INFORMATION - Group NameType SID Attributes = === Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group BUILTIN\AdministratorsAliasS-1-5-32-544 Mandatory group, Enabled by default, Enabled group, Group owner BUILTIN\Users AliasS-1-5-32-545 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\REMOTE INTERACTIVE LOGON Well-known group S-1-5-14 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\This OrganizationWell-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group Mandatory Label\High Mandatory Level Unknown SID type S-1-16-12288 Mandatory group, Enabled by default, Enabled group PRIVILEGES INFORMATION -- Privilege Name Description State === = SeIncreaseQuotaPrivilegeAdjust memory quotas for a process Disabled SeSecurityPrivilege Manage auditing and security log Disabled SeTakeOwnershipPrivilegeTake ownership of files or other objects Disabled SeLoadDriverPrivilege Load and unload device drivers Disabled SeSystemProfilePrivilegeProfile system performance Disabled SeSystemtimePrivilege Change the system time Disabled SeProfileSingleProcessPrivilege Profile single process Disabled SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled SeCreatePagefilePrivilege Create a pagefile Disabled SeBackupPrivilege Back up files and directories Disabled SeRestorePrivilege Restore files and directories Disabled SeShutdownPrivilege Shut down the system Disabled SeDebugPrivilegeDebug programs Disabled SeSystemEnvironmentPrivilegeModify firmware environment values Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled SeUndockPrivilege Remove computer from docking station Disabled SeManageVolumePrivilege Perform volume maintenance tasks Disabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled SeCreateSymbolicLinkPrivilege Create symbolic links Disabled C:\Users\Administrator -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chmod permission denied on windows 2008
- 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 worked fine on XP 2003 for years, so I dont think this is an issue. All this works fine on XP and 2003 but is there something silly I'm missing for 2008? 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? Clean 2008 RTM install, very minimal changes. You could run this under strace and see what Win32 error message you get. It could be helpful. Below is the full strace of this, but I think the issue lies where you suggested looking at:- [log] 716 22555 [main] chown 2524 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.5.25-15/winsup/cygwin/sec_helper.cc:422 windows error 1300 104 22659 [main] chown 2524 geterrno_from_win_error: unknown windows error 1300, setting errno to 13 95 22754 [main] chown 2524 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):310 val 13 94 22848 [main] chown 2524 set_privilege: -1 = set_privilege ((token 138) SeRestorePrivilege, 1) 2513 25361 [main] chown 2524 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.5.25-15/winsup/cygwin/sec_helper.cc:422 windows error 1300 93 25454 [main] chown 2524 geterrno_from_win_error: unknown windows error 1300, setting errno to 13 82 25536 [main] chown 2524 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):310 val 13 103 25639 [main] chown 2524 set_privilege: -1 = set_privilege ((token 138) SeBackupPrivilege, 1) 103 25742 [main] chown 2524 set_privilege: 1 = set_privilege ((token 138) SeChangeNotifyPrivilege, 1) [/log] Hope this gets through the lists broken spam detection, and helps id the issue. Regards Steve strace chown testuser test ** Program name: C:\cygwin\bin\chown.exe (pid 2524, ppid 1) App version: 1005.25, api: 0.156 DLL version: 1005.25, api: 0.156 DLL build:2008-06-12 19:34 OS version: Windows NT-6.0 Heap size:402653184 Date/Time:2008-07-03 22:47:05 ** 77 767 [main] chown 2524 set_myself: myself-dwProcessId 2524 91 858 [main] chown 2524 time: 1215121625 = time (0) 6681526 [main] chown 2524 environ_init: GetEnvironmentStrings returned 0x847C28 - ALLUSERSPROFILE=C:\ProgramData 1611687 [main] chown 2524 environ_init: 0x12C0238: ALLUSERSPROFILE=C:\ProgramData 1531840 [main] chown 2524 environ_init: 0x12C0260: COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files 1702010 [main] chown 2524 environ_init: 0x12C02A0: COMPUTERNAME=TEST0 1582168 [main] chown 2524 environ_init: 0x12C02B8: COMSPEC=C:\Windows\system32\cmd.exe 1492317 [main] chown 2524 environ_init: 0x12C02E0: CVS_RSH=/bin/ssh 1742491 [main] chown 2524 parse_options: ntsec (called func) 1642655 [main] chown 2524 parse_options: returning 702725 [main] chown 2524 environ_init: 0x12C02F8: CYGWIN=ntsec 1762901 [main] chown 2524 environ_init: 0x12C0320: HISTCONTROL=ignoredups 2143115 [main] chown 2524 environ_init: 0x12C0340: HISTIGNORE=[ ]*::bg:fg:exit 1563271 [main] chown 2524 getwinenv: can't set native for HOME= since no environ yet 1583429 [main] chown 2524 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\root, no-keep-rel, no-add-slash) 853514 [main] chown 2524 normalize_win32_path: C:\cygwin\root = normalize_win32_path (C:\cygwin\root) 1103624 [main] chown 2524 mount_info::conv_to_posix_path: /root = conv_to_posix_path (C:\cygwin\root) 2163840 [main] chown 2524 win_env::add_cache: posix /root 1013941 [main] chown 2524 win_env::add_cache: native HOME=C:\cygwin\root 734014 [main] chown 2524 posify: env var converted to HOME=/root 1644178 [main] chown 2524 environ_init: 0x12C0380: HOME=/root 1494327 [main] chown 2524 environ_init: 0x12C0368: HOMEDRIVE=C: 1514478 [main] chown 2524 environ_init: 0x12C04B8: HOMEPATH=\cygwin\root 1474625 [main] chown 2524 environ_init: 0x12C04D8: HOSTNAME=blade0 1474772 [main] chown 2524 environ_init: 0x12C04F0: INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:/usr/local/info:/usr/share/info:/usr/info: 1654937 [main] chown 2524 environ_init: 0x12C05E8: LOGNAME=root 1725109 [main] chown 2524 environ_init: 0x12C0600: LOGONSERVER=\\TEST0 1455254 [main] chown 2524 environ_init: 0x12C0620: MAIL=/var/spool/mail/root 1435397 [main] chown 2524 environ_init: 0x12C0640: MAKE_MODE=unix 1465543 [main] chown 2524
Re: rsync immediately hangs when connecting via ssh (still trying to fix, revisited from Aug 07)
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 produces totally erratic transfer rates and stalls due to the same issue. Regards Steve - Original Message - From: Joel Harrison [EMAIL PROTECTED] I can scp/ssh fine to the target with ssh keys installed or not, only rsync hangs immediately. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync
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 Cygwin ? I ran 'Setup.exe' but couldn't find the beast ... mind you, it's a while since I've run 'Setup.exe' for cygwin, so I might have been missing something that's obvious to the initiated. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls much slower on Vista
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 person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync windows hang
- 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 might be hanging in rsync? rsync on Windows is using no CPU when it hits this file and it does not proceed. It's far from obvious. Is your anti-virus conceivably interfering? Is the file unusually massive? Can rsync transfer a copy of the file made with dd? Can rsync transfer a copy of the file renamed? All though this may not be the case here but rsync over ssh is simply unusable under cygwin for the most part. I've tried for years to get it working reliably and its simply not possible I'm afraid. It seems related to the very slow ssh transfer issue and I suspect some low level thing to due with buffering and the way sockets are dealt with in the cygwin core is at fault. There are two options we've used in the past. rsync in daemon mode which doesn't use ssh and also doesn't seem to be as unstable or use SFU version rsync which doesn't seem to have the same issues and also has very good throughput under ssh as well. P.S. This is NOT a dig at cygwin as this is not some simple problem that can be fixed easily its a nasty timing issue thing by all investigation. Yes it would be nice to see it fixed but its one part of a very valuable system which work faultlessly for the most part. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync windows hang
- 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 it stalling yes but it really doesn't take much difference I had a 200Kb exe in a diff the other day which just wouldn't transfer. It stalled every time on startup. Some times enabling verbose and progress helps as well but not always. I ended up spending the 2 hours to get SFU installed on the host in the end it was pissing me off that much. OTOH that does suggest another question to the OP: does it make a difference whether you use rsync to pull this file or push it? This definitely makes a difference with SCP but tbh I haven't tried with rsync we always syncing from an cygwin box. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is cygwin much slower on Core 2 Duo
- 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 down other avenues. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Detecting intrusive programs in cygcheck (was: RE: SOLVED: sshd+ssh localhost connects, but don't reach the shell)
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 AnythingThisSideOfNotepad + ZoneAlarm = Disaster. Yes ZoneAlarm is a total disaster. I would hate to put a figure on the amount of PC's we've had trouble with and its turned out to be THAT!! software. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Mount points missing under chroot sftp
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 blank like the mount does not exist. Anyone got any ideas on how to fix this. I expected symlinks to other places on the fs not to work but I did expect mounts to work. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Call for testing Cygwin snapshot
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 using the new version? The experimental version did fix rsync here but broken command output unfortunately. Not sure if Corinna has had chance to look again at that as when originally tested he couldnt reproduce the results I have here i.e. missing / truncated output from remote commands. N.B. The experimental version is -p4 I've rolled back to -p3 which is not based on pipes as all commands returning missing / truncated output is unfortunately more disruptive than rsync not working. Hopefully Corinna can find some more time in his very busy schedule to have another look at this issue as nailing it would be fantastic. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
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 it works for me every time, from Linux to Cygwin. Maybe this time (only once), it's *not* Cygwin? Works fine here on: * bsd - standard cygwin build * bsd - sfu * bsd - bsd * bsd - linux So really looks like an issue with this new socketed version unfortunately. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
- 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 this at least for connections over ssh is to upload an OpenSSH test version which uses socketpairs instead of pipes for the local connection to the applications. This avoids using pipes which are the culprit here, apparently.I would mark it as experimental version, but actually the only difference would be that it would be a few per cent slower than the version using pipes. And that it probably doesn't hang. Is there interest in such a version? Yes I'd be very interested in testing this as its not only rsync that suffers from this problem, other standard ssh operations have been known to hang as well here. It is the single biggest blocker on smooth cygwin operation here and if its slightly slower that's a small price to pay for correct operation. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
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 test version which uses socketpairs instead of pipes for the local connection to the applications. This avoids using pipes which are the culprit here, apparently.I would mark it as experimental version, but actually the only difference would be that it would be a few per cent slower than the version using pipes. And that it probably doesn't hang. Is there interest in such a version? 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 when comparing this version to the baseline version of openssh. All in all this version is a massive improvement which is fantastic news!!! Many thanks Corinna. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
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 when comparing this version to the baseline version of openssh. All in all this version is a massive improvement which is fantastic news!!! Dam spoke too soon. The experimental version seems to loose output sometimes, possibly not being flushed. Here's a reproductive sequence for you. 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. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
- 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 host'n'target kernel mode debugger to get anywhere with it. Thanks for the info there Dave appreciated. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
- 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 the testcase. The fix I applied looks certainly wierd, but it works for me. Would you mind to give the next snapshot a try which should be available in a couple of minutes? 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 a go? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood
- 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 a go? http://cygwin.com/snapshots/ That's for that replacing the cygwin1.dll prevents anything from running what other steps are required? As far as I know I was running the latest release version of the cygwin1.dll The error seems fairly explanatory but apart from recompiling everything from source I wouldn't know how to progress [log] 27 [main] ? (23648) C:\cygwin\bin\bash.exe: *** fatal error - C:\cygwin\bin \bash.exe: *** system shared memory version mismatch detected - 0x75BE0096/0x75B E009B. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. [/log] Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
