A cygport build script for openssh
Hi folks, I recently downloaded the latest 'openssh' source package (5.9p1-1) via setup.exe, and was disappointed to discover that it did not come with an automated build script. Isn't every package supposed to have one? (The Cygwin Package Contributor's Guide seems to imply this.) Anyway, as a side-effect of some other work I did, I created a cygport script for openssh that (I believe) recreates the latest binary package correctly. If anyone is interested, I put a copy of the cygport script and the associated patches here: http://dev.monai.ca/cygwin/openssh-cygport/index.html The files are very small (each < 1kB); feel free to download and use them however you like. -SM -- -- 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
[ANNOUNCEMENT] Updated: md5deep-4.1-1
Version 4.1-1 of 'md5deep' has been uploaded to the Cygwin archive, and should soon appear at a Cygwin mirror near you. This version supercedes 3.6-1, which remains available as the previous version. md5deep is a set of programs to compute MD5, SHA-1, SHA-256, Tiger, or Whirlpool message digests on an arbitrary number of files. md5deep is similar to the md5sum program found in the GNU Coreutils package, but with additional features, including: recursive operation, comparison mode, time estimation, piecewise hashing, and file type mode. See the project website for all the details: http://md5deep.sourceforge.net/ -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[ANNOUNCEMENT] Updated: maradns-2.0.06-1
Version 2.0.06-1 of 'maradns' has been uploaded to the Cygwin archive, and should soon appear at a Cygwin mirror near you. This version supercedes 1.4.04-1, which remains available as the previous version. MaraDNS is a package that implements the Domain Name Service (DNS), an essential internet service. For full details, see the project website: http://www.maradns.org/ Users upgrading from 1.4.x are strongly advised take note of the significant changes introduced in version 2, as documented in /usr/share/doc/Cygwin/maradns.README . -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[ANNOUNCEMENT] Updated: maradns-1.4.04-1
Version 1.4.04-1 of 'maradns' has been uploaded to the Cygwin archive, superceding 1.4.03-2, which remains available as the previous version. MaraDNS is a package that implements the Domain Name Service (DNS), an essential internet service. For full details, see the project website: http://www.maradns.org/ According to the changelog on the project website, the changes to the MaraDNS software package since the previous release are as follows: - Bugfix: NAPTR records now work when ~ is used to separate records - NAPTR records now documented - Bugfix: ANY queries now correctly work with NS referrals - Example IPv6 addresses now use RFC-4193 compliant IPs -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 - rsync question
On 2010/09/04 9:30 AM, Dan Miller wrote: > I'm running windows XP > Cygwin with latest updates > > I have a bash script that sets up a directory structure for rsync to > perform incremental backups. It all works fine locally. > > I'd like to use the same approach to backup my local files to a windows > network share on a server. > > I have the windows network share mounted by /etc/fstab to a directory in > my root folder. Cygwin can read and create/delete files and directories > on the mount point but when I execute an rsync command from the script > it contacts the daemon and begins to send the file list but then it fails. Something doesn't quite make sense here. If you have the network share mounted in your local filesystem, then rsync should not be contacting a remote daemon, since both the source and destination are local. What is the command-line you are using to invoke rsync? > error is > > rsync: read error: Software caused connection abort (113). > > I also get a mkdir and chroot error if I try to save backup copies > within rsync. Again, what is the rsync command-line that causes this? > it seems the rsync instance doesn't have appropriate permissions on the > mounted network share. > > Is there a workaround for this ? the way I mount the share in > /etc/fstab perhaps? You mentioned that you *are* able to access files on the network share. So it is unlikely that rsync would be specifically denied access by some setting in your fstab. My suspicion is that you are invoking rsync incorrectly, but, unfortunately, you neglected to state your commands. > current mount looks like this: > > //networkshare/backup/daily /backups smbfs user,posix=0,noacl > > thanks in advance for any help. -SM -- -- 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 do I kill ssmtp?
On 2010/08/26 9:51 AM, Blaine Miller wrote: > I'm getting an inordinate amount of mail in the deadletter files, some > 400 meg since this server started. I've grepped for the PID to kill the > process, I've looked in the Services table in Windows and I've looked in > the Programs, uninstall and can't find any reference to ssmtp to kill! ssmtp is not a daemon/service, so that is to be expected. > First, is 400 meg a normal amount of dead letter mail for a system > that's been up for only two weeks? That depends on your definition of "normal". But unless your server is handling an extremely large volume of email traffic, I think it's safe to say that 400M in two weeks is not normal. > Second, how do I kill this process? You will want to find the process (or processes) that are attempting (and failing) to send email via ssmtp. In your other message to the list today, you mention that you're using cron, so I strongly suspect cron to be the source of most/all your dead emails. It is possible that your cron jobs are generating a lot of output that hasn't been redirected to proper log files or /dev/null. > Third, how do I clear the DL file? For now, I've moved the old > dead.letter to a different filed and touched a new, empty dead.letter. That sounds okay to me. You should probably examine the file contents to try to discover where the messages are coming from. > Fourth, would any of these events cause the system to completely lock up > and have to be rebooted? I don't think your dead.letter file could have caused that, unless, perhaps, it filled up the system drive. > Thanks for your time & assistance! HTH, -SM -- -- 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: The dirent struct
On 2010/08/06 8:21 PM, Chris Sutcliffe wrote: > On 6 August 2010 20:31, Steven Monai wrote: >> On 2010/08/06 11:48 AM, Chris Sutcliffe wrote: >>> I've decided to take a different approach and decided to implement it >>> as follows: >>> >>> #ifdef __CYGWIN__ >>> itr->d_fileno = entry->d_ino; >>> itr->d_reclen = strlen(entry->d_name); >>> #else >>> itr->d_fileno = entry->d_fileno; >>> itr->d_reclen = entry->d_reclen; >>> #endif >>> >>> I assume this is appropriate? >> >> No, not according to this: >> >> http://cygwin.com/ml/cygwin/2009-09/msg00031.html >> >> Quoting cgf from there: >> >> "Defining d_*rec*len as strlen(d_name) would not be correct since that >> is supposed to be the length of the record not the name." > > Interesting. From an rtorrent perspective it's working as expected, > but as I previously stated, although rtorrent grabs the value, it > doesn't actually seem to do anything with it. > > I'll leave it as is for now (I figure having something there is better > than nothing at all). IMHO, this is an unsafe approach. If, in a future version, upstream decides to start using itr->d_reclen for its intended purpose, then the plausible-but-incorrect value you've put there could become the source of Cygwin-specific bugs. In principle, if you can't/won't put the correct value there (which I see Corinna has helpfully posted), then you ought to put an obviously incorrect value there instead, such as 0 or -1. Perhaps the safest approach, though, would be to remove (or comment-out) the d_reclen field from the itr struct. Then, if upstream *does* use that field in the future, you should get build errors to alert you of that. -SM -- -- 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: The dirent struct
On 2010/08/06 11:48 AM, Chris Sutcliffe wrote: > I've decided to take a different approach and decided to implement it > as follows: > > #ifdef __CYGWIN__ > itr->d_fileno = entry->d_ino; > itr->d_reclen = strlen(entry->d_name); > #else > itr->d_fileno = entry->d_fileno; > itr->d_reclen = entry->d_reclen; > #endif > > I assume this is appropriate? No, not according to this: http://cygwin.com/ml/cygwin/2009-09/msg00031.html Quoting cgf from there: "Defining d_*rec*len as strlen(d_name) would not be correct since that is supposed to be the length of the record not the name." BTW, I look forward to trying out rtorrent in Cygwin. I am quite familiar with rtorrent, as I use it quite often in Linux. -SM -- -- 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: Moving Cygwin directory safe?
On 2010/06/27 6:37 AM, Michael Ludwig wrote: > The root directory in setup.exe is displayed correctly. Seems to depend > on the registry setting. The "Local Package Directory" path, however, > which I copied from G:\CygVar to T:\CygVar, needs fixing. Maybe another > registry setting someplace else. Have a look at the text file '/etc/setup/setup.rc'. It should contain a relevant setting named 'last-cache'. -SM -- -- 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
[ANNOUNCEMENT] New package: maradns-1.4.03-2
Version 1.4.03-2 of 'maradns' has been uploaded. This version is the initial release of the maradns package for Cygwin. The following was excerpted from the Introduction section of the MaraDNS project website, http://www.maradns.org/ : MaraDNS is a package that implements the Domain Name Service (DNS), an essential internet service. MaraDNS has the following advantages: * Secure. MaraDNS has a security history as good as or better than any other DNS server. For example, MaraDNS has always randomized, using a secure random number generator, the Query ID and source port of DNS queries; and was never vulnerable to the "new" cache poisoning attack. * Supported. MaraDNS has a long history of being maintained and updated. Actively developed since 2001, MaraDNS continues to be fully supported: The most recent release was done on February 2, 2010. Deadwood, the code that will become part of MaraDNS 2.0, is frequently updated. * Easy to use. A basic recursive configuration needs only a single three-line configuration file. A basic authoritative configuration needs only a four-line configuration file and a one-line zone file. MaraDNS is fully documented, with both easy-to-follow tutorials and a complete and up-to-date reference manual. * Small. MaraDNS is well suited for embedded applications and other environments where the server must use the absolute minimum number of resources possible. MaraDNS' binary is smaller than that of any other currently maintained recursive DNS server. * Open Source. MaraDNS is fully open-source, The license is a two- clause BSD license that is almost identical to the FreeBSD license. -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: downloading individual packages
On 2010/04/02 1:18 PM, Larry Hall (Cygwin) wrote: > ...if you're asking if there's any > other tool out there that understands the dependencies listed in setup.ini, > besides 'setup.exe', the answer is no. Well, actually... FWIW, the following (seemingly unrelated) projects at Google Code aim to provide package management for Cygwin: http://code.google.com/p/apt-cyg/ http://code.google.com/p/cyg-apt/ The former is written in bash, the latter in python. I'm not endorsing either as an "official" way of installing packages in Cygwin, but both of them do appear to use setup.ini to resolve package dependencies. -SM -- -- 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
[ANNOUNCEMENT] New package: md5deep-3.6-1
Version 3.6-1 of 'md5deep' has been uploaded. This version is the initial release of md5deep for Cygwin. The following was excerpted from the Introduction section of the md5deep project homepage, at http://md5deep.sourceforge.net/ 'md5deep' is a set of programs to compute MD5, SHA-1, SHA-256, Tiger, or Whirlpool message digests on an arbitrary number of files. md5deep is similar to the md5sum program found in the GNU Coreutils package, but with additional features, including: * Recursive operation - md5deep is able to recursively examine an entire directory tree. That is, compute the MD5 for every file in a directory and for every file in every subdirectory. * Comparison mode - md5deep can accept a list of known hashes and compare them to a set of input files. The program can display either those input files that match the list of known hashes or those that do not match. Hashes sets can be drawn from Encase, the National Software Reference Library, iLook Investigator, Hashkeeper, md5sum, BSD md5, and other generic hash generating programs. * Time estimation - md5deep can produce a time estimate when it's processing very large files. * Piecewise hashing - Hash input files in arbitrary sized blocks * File type mode - md5deep can process only files of a certain type, such as regular files, block devices, etc. This package also includes 'hashdeep', a program to compute, match, and audit hashsets. With traditional matching, programs report if an input file matched one in a set of knowns or if the input file did not match. The state of the input files compared to the set of knowns can often be more complex than anticipated. It's possible to have matched files, missing files, files that have moved in the set, and to find new files not in the set. Hashdeep can report all of these conditions. It can even spot hash collisions, when an input file matches a known file in one hash algorithm but not in others. The results are displayed in an audit report. -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: incomplete/corrupted setup.exe
On 2010/03/18 8:38 AM, Warren Young wrote: > Your proposed solutions don't really work. I disagree. Granted, they are not 100% effective, but since when is perfection the standard by which all solutions are judged? > They're crutches which may > help in some cases, but they don't absolutely and finally fix the > problem. So? Mitigating a problem means that fewer people will experience that problem. Provided that a significant proportion of the cases experience some mitigation, it can be worth implementing even an "imperfect" solution. > Therefore you're proposing that someone else do work on a > "maybe". Jeez. A guy can't throw ideas out here without people assuming they're demands for action. I was looking for a discussion of the relative merits of a few ideas. > Why are you surprised when he says "no"? I wasn't surprised. > Re the idea that SSL will defeat brain-dead and broken proxies: only the > most brain-dead among them. Corporate filtering proxies are often set > up to unwrap SSL at the proxy then re-sign the outbound request; they > see the plaintext request. Such things aren't common at the low end > because it requires adding the proxy as a trusted CA to every SSL using > program on the system, but it's common enough. Are most proxies proxying HTTPS? What proportion of them do? If a significant proportion do not, then using HTTPS can still benefit a great number of users, and it may be worth implementing (especially since HTTPS has other nice properties). > Re MITM mitigation: If that's what you're trying to guard against, how > does putting hashes on a non-HTTPS web page help? A MITM could modify > the hashes in transit just as well as he could modify setup.exe. I don't believe I proposed hashes on their own as a defense against MITM. I proposed signatures and/or authenticated transports (HTTPS) for that. Hashes can still be useful for verifying that a downloaded file is corrupt. The OP of this thread could have used a hash to verify that his file was bad, for example. > Re the MITM risk to begin with: is this actually happening, or are we > just speculating here? I pay some attention to security issues, and > haven't seen any reports of random in-flight exes over HTTP being > replaced by a MITM with malware. Could it be done? Of course. But > *is* it, and with what frequency? Good questions. I don't think there are any credible statistics on this, since it is very difficult to define and measure. The fact that MITM is feasible in several common scenarios is enough to warrant looking at simple mitigation techniques. If (some combination of) the techniques aren't too expensive when weighed against the potential risks, then they ought to be implemented. The intended use-case of setup.exe---namely, to download and run it from cygwin.com every time you want to use it---is especially vulnerable to a targeted MITM attack, since it affords the attacker any number of opportunities to deliver you an evil setup.exe. If an attacker knows you're a Cygwin user, and he's in a position to act as a MITM between you and cygwin.com at least some of the time, then you'd better carefully check every setup.exe you download before you run it. Cygwin has already implemented signatures for setup.exe (yes, I completely missed that before; Dave K. set me straight), and that is a very good thing. Detecting a MITM isn't the only problem to deal with when downloading files. Knowing when your file is truncated or otherwise corrupted---for any reason, not just malice---is also a good thing. Thinking about it some more, bypassing a web filter (regardless of whether it is well- or ill-configured) is probably not a goal to strive for. It is better to give the user some way of verifying whether the file he got is actually the file that Cygwin intended to deliver. Signatures fully cover that need, and hashes are a less expensive partial measure. HTTPS would make it simpler for more users to trust the files they do get, since verifying signatures requires additional knowledge and software that relatively few people actually have. Obviously, I'm not going to hold my breath waiting for HTTPS to appear on cygwin.com, but there is no disputing that it would improve the security of downloads. Best regards, -SM -- -- 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: incomplete/corrupted setup.exe
On 2010/03/17 10:28 PM, Dave Korn wrote: > On 18/03/2010 00:58, Steven Monai wrote: > >> As an alternative to setting up SSL on cygwin.com, what about the idea >> of crypto-signing (e.g. with gnupg) every release of setup.exe, and then >> posting the signature alongside the binary? I know I would breathe a >> little easier if I were able to positively verify the authenticity of a >> given setup.exe binary. > > That much is already done, and documented on the front page of cygwin.com: > read the first sentence under "Installing and Updating Cygwin and its > Packages" heading just beneath the mid-bar, or go straight to > http://cygwin.com/setup.exe.sig Ah, there it is. I don't know how I managed to miss that. >> The public key would need to be distributed via channels other than just >> cygwin.com, to make it more difficult to spoof. Fortunately, there are a >> number of public PGP/GPG key servers to fill that purpose. > > And we have already uploaded it to them; DSA key ID 676041BA: > > http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xA9A262FF676041BA Fantastic! Thanks. -SM -- -- 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: incomplete/corrupted setup.exe
On 2010/03/17 6:54 PM, Christopher Faylor wrote: > Oh. Are we still talking about this? I drifted off. > > Somebody please wake me when all of this tempest in a bikeshed is over. I don't understand the reason for the dismissive attitude. Pretty much every other distro posts cryptographic hashes and/or signatures with their binary downloads, so users can verify the correctness and authenticity of downloaded files. Why doesn't Cygwin do this? -SM -- -- 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: incomplete/corrupted setup.exe
On 2010/03/17 8:06 AM, Christopher Faylor wrote: > Since I haven't seen any guarantees that adding https would fix this > problem I'm not convinced that this justifies the amount of work > involved. So, until the mailing list is flooded with people who can't > download setup.exe because we don't have https access, I am satisfied > with not doing anything. That's too bad. Using SSL would nearly eliminate the risk of a MITM delivering a bogus setup.exe in place of the real thing to some unsuspecting user. As an alternative to setting up SSL on cygwin.com, what about the idea of crypto-signing (e.g. with gnupg) every release of setup.exe, and then posting the signature alongside the binary? I know I would breathe a little easier if I were able to positively verify the authenticity of a given setup.exe binary. The public key would need to be distributed via channels other than just cygwin.com, to make it more difficult to spoof. Fortunately, there are a number of public PGP/GPG key servers to fill that purpose. -SM -- -- 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: incomplete/corrupted setup.exe
On 2010/03/14 12:02 PM, Christopher Faylor wrote: > We are not going to be installing an https server in the hopes that it > will defeat misguided setup.exe blocking for the same reason that we > won't be adopting a new versioning scheme - neither is a guarantee. > > I don't mind trying to figure out clever ways to defeat Windows > limitations but I draw the line at spending nontrivial amounts of my > time trying to deal with brain-dead limitations of users' networks. > > The way to install Cygwin on your computer is to click on the "Install > Cygwin Now!" link at http://cygwin.com/ . If you can't get that to work > then you need to work with your local IT to figure out why. IT departments are becoming increasingly security conscious. That's probably why the OP had trouble downloading setup.exe. It wasn't because his IT was "brain-dead", but because there are legitimate security concerns about downloading an unsigned exe over a non-SSL-authenticated channel. I suggest people inform themselves about the current state of art in "man-in-the-middle" hijacking attacks, because the means by which cygwin.com currently distributes setup.exe is vulnerable to a MITM surreptitiously delivering a trojan setup.exe in place of the actual. For this reason, I caution Cygwin users against downloading setup.exe over unsafe networks (e.g. public wireless hotspots, hotel networks, etc.). -SM -- -- 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: incomplete/corrupted setup.exe
On 2010/03/14 10:05 AM, Jason Pyeron wrote: > Here is the proposal: > > Name setup.exe as cygwin-setup-v.vv.vv.exe or similar meaning and continue to > provide setup.exe as the most current cygwin-setup-v.vv.vv.exe (by symlink or > redirect) An additional idea: Serve setup.exe via HTTPS. That would likely defeat all but the most intrusive web-filtering proxies, and would also virtually eliminate problems caused by web caches. The costs would be relatively small: the purchase of an SSL cert, a slight increase in server load, and somebody's one-time effort to set it up. -SM -- -- 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: Feature Request: Allow cron to terminate with SIGHUP
On 2010/03/01 7:51 PM, Paul McFerrin wrote: [...] > Is there a reason [for cron] to catch SIGHUP? cron, like many UNIX daemon programs, interprets SIGHUP as a signal to close and reopen its log file. This is typically used to facilitate log file rotation. It is quite unlikely that cron's maintainer would want to change this. > I would like to keep my running of > cygwin. I knew something changed, now I know. With cron running all > the time, it is more difficult to unload cygwin1.dll. If you're not using cron for anything, you should probably just stop and permanently remove the service, e.g.: $ cygrunsrv -E cron $ cygrunsrv -R cron If you are using cron for something, then you'll have to remember to stop the cron service whenever you want/need to shut down all cygwin processes, e.g.: $ cygrunsrv -E cron This can get tedious if you have a number of cygrunsrv services installed. Here is a little bash script that should stop them all: #!/bin/bash cygrunsrv -L | while read service; do cygrunsrv -E "$service" done Hope this helped, -SM -- -- 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 ssh on win7 Non-recoverable failure in name resolution ?
On 2010/02/09 9:17 PM, William Deegan wrote: > When I try to ssh to my favorite host using my favorite username I get > the following error: > ssh: Could not resolve hostname myhost.xyz.com: Non-recoverable > failure in name resolution I see you have the 'bind' package installed, so you should have 'dig'. What do you get when you run 'dig' with no arguments? -SM -- -- 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: poll() on fifo read descriptor with non-zero timeout ==> segfault
On 2010/02/09 8:34 AM, Christopher Faylor wrote: > Relevant threads: > > http://cygwin.com/ml/cygwin/2009-12/threads.html#00685 > http://cygwin.com/ml/cygwin/2010-01/msg00067.html > > Bottom line: The crash is fixed but cygwin still doesn't work right. Doh! (face-palm) It looks like Enrico Forestieri recently discovered and reported the same issue. Please pardon my entirely redundant report. -SM -- -- 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: poll() on fifo read descriptor with non-zero timeout ==> segfault
Hi again, More information on this issue: My test case runs correctly and crash-free in Linux. This leads me to believe this is a bug in Cygwin's poll(). Even worse, after having adapted the test case to use select() instead of poll(), it appears that select() has the same bug. I've been trying to get Bernstein's 'daemontools' package to work in Cygwin, and it uses poll() to wait on a fifo's non-blocking-read descriptor in at least one program (in 'supervise', in case anyone is interested). Somehow, though, that code does not segfault. Instead, it effectively blocks forever (until killed), as all other processes are strangely prevented from writing to the fifo by "device busy" errors. Anyway, it's been quite an interesting puzzle, but I'm going to set it aside for now. Hopefully my bug report will be of some use to someone. -SM -- -- 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: Wrong setup.exe on http://www.cygwin.com/
On 2010/02/07 8:18 AM, Dave Korn wrote: > These both work: > > http://www.cygwin.com/setup.exe?&go_away_proxy! > http://www.cygwin.com/setup.exe?go_away_proxy! Nice. But of course, you would only try this if you suspect you're getting a stale 'setup.exe' from a web cache. On the server side (at cygwin.com), Apache's 'mod_expires' module could be used to send a strong hint to HTTP caches to NOT cache 'setup.exe' in the first place. After ensuring that 'mod_expires' is loaded, the addition to 'httpd.conf' could be as simple as: ExpiresActive On ExpiresDefault "now" -SM -- -- 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
poll() on fifo read descriptor with non-zero timeout ==> segfault
Hi folks,
Here is a short test case I've named "fifo-read.c":
#include
#include
#include
#include
#include
#include
struct pollfd pfd[1];
int main() {
int fifo;
int poll_result;
int timeout;
/* Open myfifo for reading, non-blocking. */
fifo = open("myfifo", O_RDONLY | O_NDELAY);
if (-1 == fifo) {
perror("open(\"myfifo\", O_RDONLY | O_NDELAY) failed");
return 1;
}
/* Set up data for poll(). */
pfd[0].fd = fifo;
pfd[0].events = POLLIN;
pfd[0].revents = 0;
timeout= -1;
fprintf(stderr, "About to enter poll()\n"); fflush(stderr);
poll_result = poll(pfd, 1, timeout);
fprintf(stderr, "Just returned from poll()\n"); fflush(stderr);
switch (poll_result) {
case -1:
perror("poll(pfd, 1, timeout) failed");
return 2;
case 0:
fprintf(stderr, "Timed out?!\n");
return 3;
}
/* At this point, read() should work. */
return 0;
}
Here's what happens at the command line:
$ uname -a
CYGWIN_NT-5.1 lonestar 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin
$ gcc-4 -Wall -Werror -ansi -pedantic -o fifo-read fifo-read.c
$ mkfifo -m0600 myfifo
$ ls -l
total 29
-rw-r--r--+ 1 steve None 939 2010-02-06 20:25 fifo-read.c
-rwxr-xr-x+ 1 steve None 22792 2010-02-06 20:25 fifo-read.exe
prw--- 1 steve None 0 2010-02-06 20:25 myfifo
$ ./fifo-read
About to enter poll()
Segmentation fault (core dumped)
If I change the timeout to a positive number, it also segfaults.
If I change the timeout to zero, it works, but poll() returns
immediately with no descriptor ready to read. Not very useful.
I get identical results on two different machines, with two different
OSes (XP and 2000). Can anyone else reproduce this? Am I using poll()
incorrectly?
Thanks,
-SM
--
--
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 Public Key Authentication problem
On 2010/02/03 10:07 PM, shane fenton wrote: > Hi, > First time poster - so hopefully will get it right :) > Cygwin 1.7 installed on approx 10 machines - XP /2008 > domain cyg_server user created > Added above user to Quotas/create token/replace token & log on as > service & local admins on pc's > added cyg_server to passwd file > ssh-host-config (found above user and used it and did the right perms > on /var/empty & /var/log/sshd.log ) > added domain user accounts to passwd & domain users group > group You didn't mention whether you set up the LSA authentication package (with /usr/bin/cyglsa-config), or used 'passwd -R' for each user. Did you try either of those? The Cygwin User Guide goes into great detail about the methods of changing user context, in this chapter: http://cygwin.com/cygwin-ug-net/ntsec.html The gist of that chapter is this: If you want to be able to login via ssh as a user that is not running the sshd daemon, you have basically two options: (1) Provide a valid Windows password to the sshd daemon, either interactively (which you obviously don't want to do, since you're attempting public key auth), or stored statically in the registry via 'passwd -R'. (2) Use the LSA authentication package. Bear in mind that if you use this option to avoid giving sshd your password entirely, I believe that certain privileges are withheld from the logged in user. [I don't remember exactly what privs are missing in this case... access to network resources maybe?] Hope this helps, -SM -- -- 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
[ANNOUNCEMENT] New package: ucspi-tcp-0.88-2
Version 0.88-2 of 'ucspi-tcp' has been uploaded. This version is the initial release of ucspi-tcp for Cygwin. Q.: What is UCSPI? A.: UCSPI stands for "UNIX Client-Server Programming Interface", which its author describes as "a command-line interface to client-server communications tools." It is suggested that UCSPI be pronounced "ooks-pie". Link: http://cr.yp.to/proto/ucspi.txt Q.: What is ucspi-tcp? A.: ucspi-tcp is a package that provides a number of command-line programs, with tcpserver and tcpclient as the two most important. tcpserver and tcpclient conform to UCSPI, and use the TCP protocol. Link: http://cr.yp.to/ucspi-tcp.html Q.: What does tcpserver do? A.: tcpserver waits for incoming TCP connections and, for each connection, runs a program of your choice. Your program receives environment variables showing the local and remote host names, IP addresses, and port numbers. tcpserver offers a concurrency limit to protect you from running out of processes and memory. When you are handling 40 (by default) simultaneous connections, tcpserver smoothly defers acceptance of new connections. tcpserver also provides TCP access control features, similar to tcp-wrappers/tcpd's hosts.allow but much faster. Its access control rules are compiled into a hashed format, so it can easily deal with thousands of different hosts. Q.: What does tcpclient do? A.: tcpclient makes a TCP connection and runs a program of your choice. It sets up the same environment variables as does tcpserver. This package includes several sample clients built on top of tcpclient: who@, date@, finger@, http@, tcpcat, and mconnect. Q.: Is there anything else you think I should know about ucspi-tcp? A.: The ucspi-tcp package for Cygwin is based on the Debian package of the same name. The man pages and IPv6 compatibility are Debian-created improvements to the original author's work. Another interesting thing to note about ucspi-tcp is that it is in the public domain. Daniel J. Bernstein, its original author, renounced his copyright ownership of it on Dec. 28, 2007. Link: http://cr.yp.to/distributors.html -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Bug: cygport fails when the working directory pathname contains spaces
On 2010/01/26 8:42 PM, Yaakov (Cygwin/X) wrote: > On 26/01/2010 20:09, Steven Monai wrote: >> $ pwd >> /home/steve/My Documents/bglibs > > This is not a bug in cygport per se. Spaces in paths is just a bad idea > when you're dealing with shell scripts and you will find all sorts of > breakage as a result (as has already been well documented on this list). Imagine if a program like 'cp' failed because the current working directory has a pathname that contains spaces. You'd probably agree with me that 'cp' had a rather serious flaw, wouldn't you? I stand by my original report. This is a bug. Not a serious show-stopper by any stretch, but a bug, nonetheless. When I find the time and motivation, I may try my hand at fixing it myself. I'll report back with patches if I do. -SM -- -- 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
Bug: cygport fails when the working directory pathname contains spaces
Hi folks, Consider this command line transcript: -- $ uname -a CYGWIN_NT-5.1 hostname 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin $ cygcheck -c cygport Cygwin Package Information Package VersionStatus cygport 0.9.80-1 OK $ pwd /home/steve/My Documents/bglibs $ ls bglibs-1.106-1.cygport $ cygport bglibs-1.106-1.cygport download /usr/bin/cygport: line 444: [: /home/steve/My: binary operator expected /usr/bin/cygport: line 450: /home/steve/My: No such file or directory -- Workaround: Move the working dir to a path not containing spaces. Best regards, -SM -- -- 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: Blitz++ Package
On 2010/01/24 7:07 PM, hughgs wrote: > I'm interested in using blitz++ in a project that I'm working on. I'm > using cygwin as my platform and couldn't find the blitz++ package on > cygwin. So, a couple of questions. > > First, am I a complete idiot and miss the package and if so can someone > point me to it? First check the official package list, here: http://cygwin.com/packages/ If no luck there, you might try checking the list of currently available packages at Cygwin Ports: home page: http://sourceware.org/cygwinports/ package list: ftp://sourceware.org/pub/cygwinports/portslist.txt > Second, if there isn't a current blitz++ package is there any interest in > one? Well, it's pretty clear there's at least one person interested! And there's no harm in putting it out there, even if there isn't much interest right now. You might end up saving someone some time later on. > I haven't ever put a package together but I figure that if I need to > build the library for myself I could at least try and build it for > everyone else (assuming there's interest). Good thinking. This page seems to be the bible on packaging for Cygwin: http://cygwin.com/setup.html . I've been studying it myself. Best regards, -SM -- -- 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: g++: -ansi flag makes snprintf() unavailable?
On 2010/01/19 8:06 PM, Eric Blake wrote: > Using -ansi generally says that you want the headers to expose ONLY the > interfaces mentioned in the C89 standard. But C89 did not describe > snprintf, hence your compilation failure. Actually, it looks like -ansi means something slightly different when used in C++ mode. According to the gcc manual, -ansi in C++ mode is equivalent to -std=c++98 , which in English means "use the 1998 ISO C++ standard plus amendments". Googling "1998 ISO C++ standard", I was able to find something that looks like an official ISO document which covers this standard, and its library does _not_ mention snprintf(), just as you stated. Thus, it appears that in this case the Cygwin compiler's behaviour is correct (i.e. to treat snprintf as undefined under -ansi), while the Debian compiler has it wrong. Interesting! > In the meantime, either don't use snprintf without declaring it by hand, > or else don't use -ansi, since they are obviously not compatible in the > current state of the headers. Will do. Thanks for your time. -SM -- -- 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
g++: -ansi flag makes snprintf() unavailable?
Hi folks,
Here is a very simple C++ test program that uses snprintf() and then
prints the result.
#include
#include
using namespace std;
int main()
{
char buf[10];
char c = 10;
snprintf( buf, sizeof(buf), "&#x%02X;", (unsigned) ( c & 0xff ) );
cout << buf << '\n'; // printf( "%s\n", buf );
return 0;
}
I compile and run this program as follows:
$ g++ -ansi -o mytest mytest.cc && ./mytest
In Debian Lenny, using g++ version 4.3.2, the program compiles and runs
successfully, producing the output I expect.
However in Cygwin 1.7, using g++ version 4.3.4, I get the following
compilation error:
mytest.cc: In function 'int main()':
mytest.cc:9: error: 'snprintf' was not declared in this scope
When I remove the -ansi flag from the compilation line, the program
builds and runs successfully in both Cygwin and Debian.
Furthermore, when I replace the cout line with a printf(), the compiler
never complains about printf(), regardless of the presence or absence of
the -ansi flag. I find that puzzling, since I'd expect printf() and
snprintf(), being related functions, to be affected in the same way by
the compilation flags.
Can anyone shed some light on this behaviour? Did the interpretation of
the -ansi flag change between gcc version 4.3.2 (Debian's) and 4.3.4
(Cygwin's)? Or is someone's compiler misbehaving?
Best regards,
-SM
--
--
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: scrotwm on cygwin
On 2010/01/11 3:22 PM, Marco Peereboom wrote: > I ported scrotwm to cygwin. Nice package. -SM -- -- 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: Update problems
On 2010/01/10 6:45 PM, Larry Hall (Cygwin) wrote: > So your argument is based on the desire to have *another* package > manager application, besides 'setup.exe', that could be used from within > Cygwin applications to update Cygwin applications? Something like that, yes. The idea that one should be able to add, remove, or upgrade a package from within the system just seems right to me. But I'll admit to being more than a little bit biased, coming from recent experience with Debian. > Doesn't that seem like > allot of duplication of effort, considering that 'setup.exe' can already do > all of this, with the only caveat being that it should be run outside of > Cygwin apps and Cygwin apps should be shut down when doing so? Relax. There is no "duplication of effort" in simply having a discussion. I realize that I'm a relative newcomer here, so some of what I've seen in this thread has been the typical exasperation of long-timers to stupid newbie questions. I also realize that 'setup.exe' is at the core of the entire Cygwin package management system, so any talk of change in this area is bound to raise hackles. I'm not trying to twist anyone's arm. Indeed, how could I, even if I wanted to? If my musings seem ridiculous and completely infeasible to you, then just ignore them, or point out the flaws. > If this really seems like a good idea to you, I'm not so full of myself that I can't admit to being wrong. I have simply asked some questions and thrown out some ideas around the topic of package management, in the hope of eliciting useful feedback. And I did get some interesting responses, particularly from Corinna and Eric. The idea that in-use files can actually be replaced within Cygwin contradicts what I had thought to be a fundamental constraint imposed by Windows. That idea, plus my recent experience with Linux package management, are what led to my initial question in this thread. I am currently not as convinced as you that package management from within Cygwin is as infeasible as you contend. But further experience, research, and play on my part could certainly change my opinion. > you should look at the > email archives where all of this has been discussed before. You need > not agree with all the conclusions drawn, etc., but it makes sense to > familiarize yourself with what's been discussed already before opening > up these kinds of old threads. I will do that. Thanks for your time. -SM -- -- 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: Update problems
On 2010/01/10 3:00 PM, Christopher Faylor wrote: > On Sun, Jan 10, 2010 at 01:28:34PM -0800, Steven Monai wrote: >> On 2010/01/10 12:31 PM, Eric Blake wrote: >>> According to Christopher Faylor on 1/10/2010 12:27 PM: >>>> No one thinks its a good idea. >>> >>> And here's one reason why. Newer versions of cygwin1.dll introduce new >>> entry points. But suppose you are updating cygwin1.dll and bash at the >>> same time. If the new bash depends on one of those new entry points, but >>> the old cygwin1.dll is still in operation, then the replace-on-reboot >>> won't save the fact that the new bash won't work until the reboot. >> >> Okay, that is definitely a problem with my scenario. We don't want to >> force an otherwise needless reboot every time cygwin1.dll is updated. >> >> But what you describe is also a problem for setup.exe right now. To >> reuse your example, if I run setup.exe to upgrade bash but I don't >> upgrade cygwin1.dll at the same time (for whatever reason), then the new >> bash won't work. More generally, if I upgrade package 'foo' but not >> package 'bar'---and 'foo' uses new features of the new 'bar'---then >> 'foo' will not work. > > Yes, if you do something brain-dead you can expect bad results. There can be non-"brain-dead" reasons for attempting to upgrade one package while holding another related one at a specific version. Granted, the situations where one might want to do this are probably few and far between, but I suspect that the scenario Eric described is also quite rare. > That is > different from doing a normal install, expecting things to work and > being bitten by a non-updated cygwin DLL. In my scenario, you would not be bitten by a non-updated cygwin DLL if you rebooted after the update. The package manager could even give the user a message like "A reboot is needed to complete the update. Things may not work correctly until you do.". Most Windows users are probably used to that sort of thing already. >> Other package management systems deal with this problem by including >> versioning in the package dependency specification. Thus one could, for >> example, specify that 'foo' version 1.1 depends on 'bar' version >= 2.4. >> So if I upgrade 'foo' to version 1.1, an upgrade to 'bar' is forced if >> the currently installed 'bar' has version < 2.4. > > Now you've offered YA observation which has been made before. And it's > one that would fix your hypothetical situation and not really touch the > original concern unless you want to hold off all updates until the next > reboot. A reboot would be required only in the special case of an update to 'cygwin1.dll'. In all other cases, no reboot would be required, and neither Eric's scenario, nor my generalization of it, would ever occur. -SM -- -- 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: Update problems
On 2010/01/10 12:31 PM, Eric Blake wrote: > According to Christopher Faylor on 1/10/2010 12:27 PM: >> No one thinks its a good idea. > > And here's one reason why. Newer versions of cygwin1.dll introduce new > entry points. But suppose you are updating cygwin1.dll and bash at the > same time. If the new bash depends on one of those new entry points, but > the old cygwin1.dll is still in operation, then the replace-on-reboot > won't save the fact that the new bash won't work until the reboot. Okay, that is definitely a problem with my scenario. We don't want to force an otherwise needless reboot every time cygwin1.dll is updated. But what you describe is also a problem for setup.exe right now. To reuse your example, if I run setup.exe to upgrade bash but I don't upgrade cygwin1.dll at the same time (for whatever reason), then the new bash won't work. More generally, if I upgrade package 'foo' but not package 'bar'---and 'foo' uses new features of the new 'bar'---then 'foo' will not work. Other package management systems deal with this problem by including versioning in the package dependency specification. Thus one could, for example, specify that 'foo' version 1.1 depends on 'bar' version >= 2.4. So if I upgrade 'foo' to version 1.1, an upgrade to 'bar' is forced if the currently installed 'bar' has version < 2.4. > Really, it is better to stop ALL things cygwin, do the upgrade, and not > worry about those interactions. I would say it is certainly EASIER to do it that way, not necessarily that it is better. Thank you for your time. -SM -- -- 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: Update problems
On 2010/01/09 2:09 AM, Corinna Vinschen wrote: > On Jan 8 17:28, Steven Monai wrote: >> Not to beat a dead hippo here, but if Cygwin allows in-use files to be >> replaced, then what is 'setup.exe' needed for? (Aside from the initial >> bootstrap of Cygwin, of course.) Shouldn't it be possible to have proper >> package management---like dpkg, apt, rpm, yum, etc---from within Cygwin now? > > The most pressing problem is the replacement of the cygwin DLL itself. > It's like installing a new kernel in Linux. However, in Linux you have > to reboot to use the new kernel, while Cygwin is just a DLL. After the > rename and replace operation, existing processes will use the old DLL > while new processes will use the new DLL. This is bound to break and > there's no clean way to do it, except to replace the Cygwin DLL while no > other Cygwin process is running. Could a Cygwin-specific package manager treat the cygwin DLL as a special case? Instead of immediately replacing the cygwin DLL file (as it would normally do for any other DLL), the package manager could use the Windows "schedule-a-delete/rename-on-reboot" facility to arrange for the DLL's replacement at the next reboot. Thus there would never be more than one version of the cygwin DLL loaded at any given time. -SM -- -- 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: question with cygwin.bat and Windows Scheduler
On 2010/01/09 8:42 PM, Steven Monai wrote: > On 2010/01/09 7:02 PM, aviate wrote: >> I was avoiding cron...but it might be most useful here. Is there any >> way to >> hide the window popping up by Windows Scheduler?? > > Yes there is. Duh, just replying to myself to let you know that there's an even simpler way to get the effect you wanted, and you don't even need 'run.exe'. You can directly schedule 'bash.exe' to run in the Task Scheduler. The command line to schedule for execution is as follows: C:\cygwin\bin\bash.exe --login -c "/myfolder/myscript.sh" -SM -- -- 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: question with cygwin.bat and Windows Scheduler
On 2010/01/09 7:02 PM, aviate wrote: > I was avoiding cron...but it might be most useful here. Is there any > way to > hide the window popping up by Windows Scheduler?? Yes there is. Install the Cygwin 'run' package (if not installed already). Use the Windows Task Scheduler interface to schedule the following command line for execution: C:\cygwin\bin\run.exe bash -wait --login -c "/myfolder/myscript.sh" That's it. Your bash script should run in a "hidden" console window at the scheduled times. What's really nice is that with 'run', you don't need to have a separate .bat file. Oh, and I guess you won't need cron. -SM -- -- 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: question with cygwin.bat and Windows Scheduler
On 2010/01/09 5:36 PM, aviate wrote: > > Hi...tried for a long, long time trying to make this work to no avail...and > did not find help online. > > Using Windows XP, I am running a bash script via the windows task scheduler, > which is calling Cygwin.bat ...The command being tasked is: > > C:\cygwin\Cygwin.bat /myfolder/myscript.sh You're using 'Cygwin.bat' in a way it wasn't meant to be used. 'Cygwin.bat' is for opening an interactive shell in a Windows console window, not for running arbitrary bash scripts. Instead, create a separate .bat file to run your bash script. The following two-liner should do the trick: @echo off C:\cygwin\bin\bash.exe --login -c "/myfolder/myscript.sh" Name the file something like "myscript.bat", and schedule it to run in Task Scheduler. Now every time it runs, a console window will open, and within it you'll see your bash script's output. The window will automatically close when the bash script exits. Finally, you may want to look into using Cygwin's 'cron' package instead of Task Scheduler. One benefit of using cron is that you won't get a console window popping open every time the script runs. HTH, -SM -- -- 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 hanging
On 2010/01/09 7:10 AM, Kevin Bond wrote: > Hello, I am trying to use rsync in cygwin but it seems to be hanging. > Right after it asks me for password of my host the 'building file > list...' message displays then hangs. I can ssh into the host fine. > > Any ideas? One idea: http://rsync.samba.org/issues.html Another idea: http://cygwin.com/problems.html Feel free to apply those ideas in any order. -SM -- -- 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: Update problems
On 2010/01/08 2:38 PM, Larry Hall (Cygwin) wrote: > On 01/08/2010 03:41 PM, Christian Franke wrote: >> Larry Hall (Cygwin) wrote: >>> On 01/07/2010 09:39 PM, David Gast wrote: There are two problems with updating cygwin. 1. If you run setup.exe from bash, bash cannot be updated because the file is in use. >>> >>> Sure. This is the reason 'setup.exe' exists. It's a Windows >>> "feature" that keeps you from replacing a file that's in use. >>> 'setup.exe' was created to provide a native Windows program >>> to avoid the problem of something like 'setup.exe' needing to >>> update files that are in use by it. If it were possible to >>> replace files in use with the same ease as on Linux, say, >>> then 'setup.exe' would never be needed since things like >>> rpm, yum, and apt, to name a few, could be used directly >>> to install and update Cygwin. >> >> Cygwin 1.7 actually allows to replace an executable which is still in >> use: >> http://cygwin.com/ml/cygwin/2009-12/msg00423.html > > But this is of no help here. The fact that Cygwin has this feature > internally > won't make 'setup.exe' use it. If someone wants to offer a patch for > 'setup.exe' > to make it be able to be run from a Cygwin shell, I'm sure it will be > thoughtfully > considered. Not to beat a dead hippo here, but if Cygwin allows in-use files to be replaced, then what is 'setup.exe' needed for? (Aside from the initial bootstrap of Cygwin, of course.) Shouldn't it be possible to have proper package management---like dpkg, apt, rpm, yum, etc---from within Cygwin now? Just wondering. -SM -- -- 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 no longer preserves extended ASCII characters after 1.7 upgrade
On 2009/12/27 11:12 PM, Andy Koppe wrote: > But I think the --iconv option is the better way. Assuming you want to > stick with ISO-8859-1 on the Linux side, '--iconv utf8,iso88591' > should do the job. Regarding using the '--iconv' option in rsync transfers from Cygwin (charset UTF-8) to Linux (charset ISO-8859-1): I just checked the rsync man page again, and I thought I would follow up with some additional info. If rsync is invoked from the Cygwin side, then the option to use is '--iconv=UTF-8,ISO-8859-1'. Conversely, if invoked from the Linux side, one would use '--iconv=ISO-8859-1,UTF-8'. [The convention is: --iconv=,.] Finally, if both ends of the transfer have sane locale/charset settings, one can simply use '--iconv=.' to tell rsync to automatically determine and apply the appropriate conversion. Incidentally, I ran some sample rsync transfers from Cygwin 1.7.1 (with default locale/charset) to Debian 5.0.3 (set to en_CA.ISO-8859-1), and the '--iconv' option functioned correctly every time. -SM -- -- 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 no longer preserves extended ASCII characters after 1.7 upgrade
On 2009/12/27 7:56 PM, Adam Rosi-Kessel wrote: > Adam Rosi-Kessel wrote, on 12/27/2009 10:41 PM: >> I'm running cygwin on a WinXP system with an NTFS-formatted drive. I >> have a script that regularly backs up using rsync onto a Linux system >> (Debian) with an ext3 drive. >> >> Before the recent major upgrade, all extended ASCII characters were >> preserved perfectly without any special rsync switches. E.g., é stayed >> as é (assuming that character will survive this mailing list post -- >> accented e). >> >> Now, all accented characters appear as ? on the target linux system. > > Actually, this is a little more complicated than I thought. When I mount > the rsync target linux drive as a Samba share from the WinXP box, the > files appear to have the correct accents on the destination. But when I > view them from the linux box, they have scrambled accents -- either just > ?'s if I use ls (must be a terminal issue), or different nonstandard > characters that aren't the right extended characters if I redirect the > output to a file and then view that. > > I'm just trying to get back the behavior from before the upgrade. Thanks > for any suggestions. Assuming you upgraded from 1.5.x to 1.7.1, Cygwin has new default locale/charset settings that affect filename handling. Have a look at the Cygwin User Guide, specifically the page on Internationalization, here: http://cygwin.com/cygwin-ug-net/setup-locale.html I'm not sure what the default locale/charset was for 1.5.x, but for 1.7.1, it is "C.UTF-8". You may be able to get the old behaviour back by setting LANG (or LC_ALL or LC_CTYPE) in Cygwin to match the locale/charset of your Linux system. -SM -- -- 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: Change to current directory to %appdata% folder.
On 2009/12/12 6:29 PM, Hongyi Zhao wrote: > Hi all, > > I want to change to current directory to %appdata% folder by using > some command within cygwin. Is this possible? This command: cd "$APPDATA" works for me. HTH, -SM -- -- 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
1.7.0-64: cygserver linked against cygstdc++-6.dll (libstdc++6)
In 1.7.0-64, /usr/sbin/cygserver is linked against cygstdc++-6.dll. cygserver will not run (exit status 128) unless the 'libstdc++6' package is installed. -SM -- -- 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 rsync 3.0.6-1 under 1.7.0-62 and 63
Eliot Moss wrote: > There does > not seem to be anything like this reported in the rsync list, > so I think it's particular to cygwin, and probably to 1.7.x. I really think you should report what you're seeing to the rsync mailing list. It is entirely possible that no one who has run your particular use case before (rsync v3.0.6 failing to work with rsync v2.6.8, and vice versa) has ever gone to the extra effort of reporting the problem. In the best case, the rsync gurus may be able to look at your error codes and tell right away what is going wrong. They may even agree with your assessment that Cygwin is somehow to blame, although I'd lean more towards a protocol mismatch hypothesis. -SM -- -- 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: Why do 'find' and 'ls' act differently on ACLs
aputerguy wrote: > Why do 'ls and 'find' seem to treat the ACL restrictions differently. They definitely should not. If they do, then there's a bug to be squashed. > Specifically, 'ls /c/Documents and Settings/Administrators' works > while 'find /c/Documents and Settings/Administrators' returns: >find: `/c/Documents and Settings/Administrator/': Permission denied I cannot replicate this behaviour. Can you provide a minimal test case that reliably demonstrates what you're seeing? A short script that creates some data, sets some particular ACLs, and then invokes 'ls' and 'find' would be ideal. -SM -- -- 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 rsync 3.0.6-1 under 1.7.0-62 and 63
Eliot Moss wrote:
>> Eliot Moss wrote:
>>> I am getting this output when trying to rsync
>>> to any of several systems. I have RSYNC_RSH set
>>> to use ssh, and the ssh commands work just fine.
>>> This smells like some kind of non-matching library
>>> issue to me ...
>>>
>>> rsync: Failed to dup/close: Bad file descriptor (9)
>>> rsync error: error in IPC code (code 14) at
>>> /home/lapo/packaging/rsync-3.0.6-1/src/rsync-3.0.6/pipe.c(72)
>>> [sender=3.0.6]
>>> rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]:
>>> Connection reset by peer (104)
>>> rsync error: error in IPC code (code 14) at
>>> /home/lapo/packaging/rsync-3.0.6-1/src/rsync-3.0.6/io.c(1525)
>>> [sender=3.0.6]
...
> The command line is:
>
> rsync -avzuP UK-2009-11-richards-gist ${REMOTE_HOST}:talks/
I assume you ran the above command in Cygwin. (Note that I have replaced
the remote hostname with ${REMOTE_HOST}.)
Is the remote host also running Cygwin? If so, what version? If not,
then what is the remote OS ?
What output do you get when you run the following in Cygwin (after
setting REMOTE_HOST appropriately, of course):
ssh "${REMOTE_HOST}" /bin/true | od -tx1
-SM
--
--
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 rsync 3.0.6-1 under 1.7.0-62 and 63
Eliot Moss wrote: > I am getting this output when trying to rsync > to any of several systems. I have RSYNC_RSH set > to use ssh, and the ssh commands work just fine. > This smells like some kind of non-matching library > issue to me ... > > rsync: Failed to dup/close: Bad file descriptor (9) > rsync error: error in IPC code (code 14) at > /home/lapo/packaging/rsync-3.0.6-1/src/rsync-3.0.6/pipe.c(72) > [sender=3.0.6] > rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: > Connection reset by peer (104) > rsync error: error in IPC code (code 14) at > /home/lapo/packaging/rsync-3.0.6-1/src/rsync-3.0.6/io.c(1525) > [sender=3.0.6] I am curious to know: What is the specific command-line you're using to invoke rsync when it produces the above output? Yours may not be a Cygwin-specific problem, as I routinely use rsync over ssh on 1.7.0-63, and I have never seen that. The rsync mailing list is another resource you could try. The 'rsync FAQ' and 'rsync current issues' pages (google them) may also be of help. -SM -- -- 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-63
Corinna Vinschen wrote: ... > Bugfixes: > = ... > - Improve the roundtrip capability when converting singlebyte chars to > the UNICODE prvate use area U+F0xx and vice versa. Fantastic! I just upgraded from 1.7.0-62 to -63, and my daily rsync backup script can now see that handful of files on my system with "weird" names [containing Unicode char U+F020] that were previously untouchable by Cygwin. Just wondering: What limitations, if any, are there now on the chars from the U+F0xx range that can be used in filenames? -SM -- -- 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: SOLVED: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode
Andy Koppe wrote: > Any idea how that U+f020 character had got in there in the first place? Someone probably discovered the Windows Character Map app, and decided it would be fun to put some weird chars into their filenames. I guess I'll have to ask my colleagues not to use chars from the Unicode private use range (U+f000 to U+f0ff) when they do this. -SM -- -- 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: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode
Corinna Vinschen wrote: >>22 12422 [main] ls 1300 fhandler_disk_file::readdir_helper: wchar >> filename: "Mikey12\xf020.ai" > > That's the problem. The character in that file is *not* U+0323, but > U+f020, a character in the Unicode private use range, which is used in > Cygwin to map ASCII characters invalid in Windows filenames but valid > in POSIX filenames. It's also used to map multibyte characters > 0x80 > which are invalid in the current charset. Thanks for diagnosing my problem. My assumption that the char was U+0323 was based on scrolling through the Windows Character Map app for something that visually matched what I was seeing in the filename. Not having any other way to quantify the char, I jumped to an incorrect conclusion. This also explains why my test on another machine produced the correct result. Instead of actually copying the troublesome file over to that machine, I lazily created a filename there containing the char (U+0323) I presumed to be causing trouble on the first machine. I have since verified that the char U+0323 works fine in filenames on all my Cygwin 1.7 boxes, while the char U+f020 fails on all of them. > You must not use characters > in this range from U+f000 up to U+f0ff. There's no solution to this > except for "don't use these characters in filenames if they are not > explicitely written there by either Cygwin or Microsoft's SUA". The above two sentences should probably go into the UG. > See > http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-specialchars That section of the UG only says that certain special chars are mapped by Cygwin into the 0xf000 to 0xf0ff range. It does not explicitly say that Cygwin may not be able to deal with filenames containing arbitrary chars from that range, hence my suggestion that the UG be updated. Thanks again, -SM -- -- 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: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode
Corinna Vinschen wrote: > Can I send you a link to another Cygwin > DLL in private email, which I tweaked to get better debug output? Yes, of course. I greatly appreciate your interest in trying to resolve this problem. -SM -- -- 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 link-dest not working for a host with the most recent rsync/cygwin 1.7
Chris Francy wrote: > On Thu, 22 Oct 2009 20:08 PM, Steven Monai wrote: >> Could you re-run your Cygwin-1.7 test case with --itemize-changes added >> to the rsync command-line? That should provide a hint at what Debian's >> rsync thinks is different between its existing file copy and Cygwin's >> source file. Also, I would like to see what Cygwin's 'stat' command says >> about the source file on the Windows box. > > The output of stat of my testfile on the box with cygwin 1.7 is > > stat testfile > File: `testfile' > Size: 1048576 Blocks: 1024 IO Block: 65536 regular file > Device: bcdb6416h/3168494614d Inode: 27303072741079683 Links: 1 > Access: (0700/-rwx--) Uid: (4294967295/ UNKNOWN) Gid: ( 401/mkpasswd) > Access: 2009-10-20 23:37:29.577294700 -0700 > Modify: 2009-10-21 00:36:28.0 -0700 > Change: 2009-10-20 23:37:30.030425500 -0700 > > Here (http://pastebin.com/m6c414439) is the output of my rerunning my > tests against the server with cygwin 1.7 with the --itemize-changes > and -vv rsync options. Notice that the Uid/Gid of 'testfile' on Cygwin 1.7 is a bit crazy. It is likely that '/etc/passwd' and/or '/etc/group' have not been set up correctly on that box. On the Debian side, it appears that rsync is unable to preserve ownership when presented with that strange Uid, instead saving the file with Uid/Gid = 0/0. (Presumably, rsync is running as 'root' on the Debian box.) On subsequent runs, Debian's rsync determines that the source file and its local copy are different, because the source Uid (4294967295) is different from the local Uid (0). Thus, when asked to preserve ownerships, rsync with the --link-dest option effectively never creates any hard links. That explains why omitting --owner and --group from the rsync command line is a passable work-around in your case. Arguably, a better solution might be to get sane Uid/Gids associated with files on the Cygwin box, but only you can decide whether the effort would be worth it. (It may be as simple as running 'mkpasswd' and 'mkgroup' with appropriate options.) -SM -- -- 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: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode
Corinna Vinschen wrote: > I'm seriously puzzled. Could you please run > > $ strace -o ls.trace ls -l weird/ > > and send the ls.trace file as attachment? Maybe there's some hint > in it. Done. -SM -- 3 3 [main] ls 288 open_shared: name shared.5, n 5, shared 0x60FC (wanted 0x60FC), h 0x770 198 201 [main] ls 288 heap_init: heap base 0x68, heap top 0x68 59 260 [main] ls 288 open_shared: name S-1-5-21-1343024091-688789844-1708537768-500.1, n 1, shared 0x60FD (wanted 0x60FD), h 0x76C 33 293 [main] ls 288 user_shared_create: opening user shared for 'S-1-5-21-1343024091-688789844-1708537768-500' at 0x60FD 29 322 [main] ls 288 user_shared_create: user shared version 2E710001 47 369 [main] ls 288 events_init: windows_system_directory 'C:\WINDOWS\system32\', windows_system_directory_length 20 115 484 [main] ls 288 dll_crt0_0: finished dll_crt0_0 initialization 73 557 [main] ls 288 _cygtls::remove: wait 0x 32 589 [main] ls 288 _cygtls::remove: removed 0x22CE64 element 0 43 632 [main] ls 288 _cygtls::remove: wait 0x 21 653 [main] ls 288 _cygtls::remove: removed 0x22CE64 element 0 166 819 [sig] ls 288 wait_sig: entering ReadFile loop, my_readsig 0x74C, my_sendsig 0x748 10895 11714 [main] ls 288 _cygwin_istext_for_stdio: fd 0: not open 112 11826 [main] ls 288 _cygwin_istext_for_stdio: fd 1: not open 18 11844 [main] ls 288 _cygwin_istext_for_stdio: fd 2: not open 180 12024 [main] ls 288 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Administrator, no-keep-rel, no-add-slash) 42 12066 [main] ls 288 normalize_win32_path: C:\cygwin\home\Administrator = normalize_win32_path (C:\cygwin\home\Administrator) 25 12091 [main] ls 288 mount_info::conv_to_posix_path: /home/Administrator = conv_to_posix_path (C:\cygwin\home\Administrator) 77 12168 [main] ls (288) open_shared: name cygpid.288, n 288, shared 0x60FF (wanted 0x60FF), h 0x724 161 12329 [main] ls 288 ** 18 12347 [main] ls 288 Program name: C:\cygwin\bin\ls.exe (pid 288, ppid 1) 16 12363 [main] ls 288 App version: 1007.0, api: 0.189 17 12380 [main] ls 288 DLL version: 1007.0, api: 0.214 16 12396 [main] ls 288 DLL build:2009-10-03 14:33 21 12417 [main] ls 288 OS version: Windows NT-5.1 16 12433 [main] ls 288 Heap size:402653184 17 12450 [main] ls 288 ** 16 12466 [main] ls 288 pinfo::thisproc: myself->dwProcessId 288 19 12485 [main] ls 288 time: 1256742369 = time (0) 293 12778 [main] ls 288 parse_options: glob (called func) 41 12819 [main] ls 288 parse_options: returning 18 12837 [main] ls 288 environ_init: GetEnvironmentStrings returned 0x1 33 12870 [main] ls 288 environ_init: 0x6A8298: !::=::\ 32 12902 [main] ls 288 environ_init: 0x6A82A8: !C:=C:\cygwin\bin 35 12937 [main] ls 288 environ_init: 0x6A82C0: ALLUSERSPROFILE=C:\Documents and Settings\All Users 34 12971 [main] ls 288 environ_init: 0x6A8300: APPDATA=C:\Documents and Settings\administrator\Application Data 34 13005 [main] ls 288 environ_init: 0x6A8348: COMMONPROGRAMFILES=C:\Program Files\Common Files 34 13039 [main] ls 288 environ_init: 0x6A8380: COMPUTERNAME=DATASERVER 33 13072 [main] ls 288 environ_init: 0x6A83A0: COMSPEC=C:\WINDOWS\system32\cmd.exe 34 13106 [main] ls 288 environ_init: 0x6A83D0: CVS_RSH=/bin/ssh 33 13139 [main] ls 288 environ_init: 0x6A83E8: CYGWIN=noglob 31 13170 [main] ls 288 environ_init: 0x6A8400: EDITOR=nano 31 13201 [main] ls 288 environ_init: 0x6A8418: FP_NO_HOST_CHECK=NO 33 13234 [main] ls 288 getwinenv: can't set native for HOME= since no environ yet 22 13256 [main] ls 288 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Administrator, no-keep-rel, no-add-slash) 22 13278 [main] ls 288 normalize_win32_path: C:\cygwin\home\Administrator = normalize_win32_path (C:\cygwin\home\Administrator) 18 13296 [main] ls 288 mount_info::conv_to_posix_path: /home/Administrator = conv_to_posix_path (C:\cygwin\home\Administrator) 47 13343 [main] ls 288 win_env::add_cache: posix /home/Administrator 88 13431 [main] ls 288 win_env::add_cache: native HOME=C:\cygwin\home\Administrator 20 13451 [main] ls 288 posify: env var converted to HOME=/home/Administrator 43 13494 [main] ls 288 environ_init: 0x6A84A0: HOME=/home/Administrator 33 13527 [main] ls 288 environ_init: 0x6A8438: HOMEDRIVE=C: 34 13561 [main] ls 288 environ_init: 0x6A84C0: HOMEPATH=\Documents and Settings\administrator 34 13595 [main] ls 288 environ_init: 0x6A84F8: HOSTNAME=dataserver 32 13627 [main] ls 288 environ_init: 0x6A8518: INFOPATH=/usr/local/info:/usr/share/info:/usr/info: 32 13659 [main] ls 288 environ_init: 0x6A8558: LOGONSERVE
Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode
Hello folks,
I recently removed Cygwin 1.5.25 from a WindowsXP box (as per FAQ #
2.17), and then installed the Cygwin 1.7.0 beta in its place. The
install seemed to go flawlessly. I was looking forward to having more
robust handling of filenames with Unicode chars, but unfortunately, I'm
not having much luck.
For example, the following is some output from a bash shell interaction:
$ ls -l weird/
ls: cannot access weird/Mikey12 .ai: No such file or directory
total 0
-? ? ? ? ?? Mikey12 .ai
The directory named 'weird' has a single file in it named 'Mikey12?.ai',
where '?' is the Unicode char U+0323 ("Combining Dot Below").
None of the other Cygwin command line tools I tried could access the
file either. Most importantly to me, 'rsync' can't do anything with it.
rsync always reports that the "file vanished".
I added 'set LC_ALL=en_US.UTF-8' (without the quotes) to Cygwin.bat, as
suggested in the Internationalization section of the 1.7 User Guide, but
there was no improvement.
Any ideas about what might be going wrong? I'm not seeing the same
problem on another machine (Windows 2000 SP4), where no version of
Cygwin previous to 1.7.0 was ever installed. Could it be that some
remnant of the previous Cygwin 1.5 install is causing my problem?
Output of 'cygcheck -svr' is attached.
Thanks,
-SM
--
Cygwin Configuration Diagnostics
Current System Time: Mon Oct 26 15:50:16 2009
Windows XP Professional Ver 5.1 Build 2600 Service Pack 3
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 10500(Administrator) GID: 10513(Domain Users)
545(Users) 544(Administrators)
10512(Domain Admins) 10513(Domain Users)
10519(Enterprise Admins) 10520(Group Policy Creator Owners)
10518(Schema Admins)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 10500(Administrator) GID: 10513(Domain Users)
545(Users) 544(Administrators)
10512(Domain Admins) 10513(Domain Users)
10519(Enterprise Admins) 10520(Group Policy Creator Owners)
10518(Schema Admins)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
USER = 'Administrator'
PWD = '/home/Administrator'
HOME = '/home/Administrator'
HOMEPATH = '\Documents and Settings\administrator'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\administrator\Application Data'
HOSTNAME = 'dataserver'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 12 Stepping 0, AuthenticAMD'
WINDIR = 'C:\WINDOWS'
OLDPWD = '/usr/bin'
USERDOMAIN = 'EXAMPLE'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
USERNAME = 'Administrator'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Documents and Settings\administrator'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\SATURN'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
USERDNSDOMAIN = 'EXAMPLE.COM'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0c00'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'Console'
COMPUTERNAME = 'DATASERVER'
_ = '/usr/bin/cygcheck'
HKEY_CURRENT_USER\Console\Shortcut to Cygwin.bat
(default) = 0x0007
PopupColors = 0x00f5
ColorTable00 = 0x
ColorTable01 = 0x0080
ColorTable02 = 0x8000
ColorTable03 = 0x00808000
ColorTable04 = 0x0080
ColorTable05 = 0x00800080
ColorTable06 = 0x8080
ColorTable07 = 0x00c0c0c0
ColorTable08 = 0x00808080
ColorTable09 = 0x00ff
ColorTable10 = 0xff00
ColorTable11 = 0x0000
ColorTable12 = 0x00ff
ColorTable13 = 0x00ff00ff
ColorTable14 = 0x
ColorTable15 = 0x00ff
InsertMode = 0x0001
QuickEdit = 0x0001
FullScreen = 0x
ScreenBufferSize = 0x012c0050
WindowSize = 0x00190050
FontSize = 0x0012000a
FontFamily = 0x0030
FontWeight = 0x0190
FaceName = 'Terminal'
CursorSize = 0x0019
HistoryBufferSize = 0x0032
NumberOfHistoryBuffers = 0x0004
HistoryNoDup = 0x
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
(default) = 'C:\cygwin'
obcaseinsensitive set to 1
a: fd N/AN/A
email package dependency (openssl) not automatically installed
Hello folks, I installed a fresh Cygwin 1.7 beta, and added the 'email' package. Then, I ran the following to send myself a test message: $ echo "Test message" | email --subject="Test" \ > --smtp-server="smtp.at.my.isp" --from-name="Steven Monai" \ > --from-addr="steve+cyg...@monai.ca" steve+cyg...@monai.ca /usr/bin/email.exe: error while loading shared libraries: cygssl-0.9.8.dll: cannot open shared object file: No such file or directory Whoops. Is there something wrong with 'openssl'? $ cygcheck -c email openssl Cygwin Package Information Package VersionStatus email3.1.2-2OK No 'openssl'. So 'email' was installed, but at least one of its dependencies wasn't. Could this be an 'email' packaging bug? Anyway, after installing 'openssl', 'email' works just fine. -SM -- -- 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 link-dest not working for a host with the most recent rsync/cygwin 1.7
Chris Francy wrote: > First things first, I have narrowed it down and learned something that > resolves the issue for what I am trying to do. > > For versions of rsync before 2.5.6 you could not use the link-dest > reliably unless you copy the permissions/ownership information. With > newer versions of rsync this is not necessary. Glad you were able to figure out a work-around. And it's good to know what worked for you, for future reference. ... > So to demonstrate the link-dest function on my linux box here is a > simple example using relative directories including the output on my > backup server (debian linux 5.0) (http://pastebin.com/m191da91f). > > I have a test case (http://pastebin.com/m6797debc) that I ran against > both two of my systems to demonstrate the difference in behavior. > > Here (http://pastebin.com/m77f9f3b6) is my output when I run the > command on my backup server to get the stuff off my 1.5 host. > > Here (http://pastebin.com/m29252e) is my output when I run the command > on my backup server to get the stuff off my 1.7 host. In this case > the test file in the two destination directories are not hard linked > together like in the 1.5 case. I also noticed that in the the uid/gid > is set differently compared to the 1.5 system. > > So it appears something about permissions isn't coming across the same > as it was on cygwin 1.5. Likely. But that doesn't really answer the question of *why* link-dest is failing to work properly when ownerships and perms are preserved. Even if Cygwin-1.7's rsync is sending bollixed up uid/gid/perms to Debian's rsync, link-dest on the Debian side should still work. Since link-dest is not working, I infer that either: (1) For any given unchanged file, Cygwin-1.7's rsync reports a different set of uid/gid/perms values every time it runs. OR (2) Debian's rsync is unable to faithfully preserve the uid/gid/perms values of files previously saved from Cygwin-1.7's rsync, so that every time such a backup is run, Debian rsync sees the uid/gid/perms as changed. I don't think (1) is at all likely, simply because I can't imagine how such a bug would go undetected for so long. My hypothesis is the problem could be (2). > Since I don't care about the retaining the > permissions, and I now have a version of rsync on both sides that > allows me to use link-dest without copying permissions I am happy. If > someone wants to continue digging into this further I am still > available. Thanks in advance for indulging me just a little bit further. Could you re-run your Cygwin-1.7 test case with --itemize-changes added to the rsync command-line? That should provide a hint at what Debian's rsync thinks is different between its existing file copy and Cygwin's source file. Also, I would like to see what Cygwin's 'stat' command says about the source file on the Windows box. -SM -- -- 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 link-dest not working for a host with the most recent rsync/cygwin 1.7
Chris Francy wrote: > It appears something about the about rsync or the 1.7 version of > cygwin is preventing the --link-destination function of rsync from > working. Files that have not been changed at all should be linked > together. On the hosts still running a cygwin 1.5 version of rsync > the link-destination seems to work exactly as I expect it to. > > I am using dirvish (http://www.dirvish.org/) on a Linux box (deb > 5.0.3) to backup some of the data on windows boxes in the network. I > have the cygwin+rsync setup in daemon mode on the servers. I recently > upgraded a couple of the boxes to the latest cygwin 1.7. On the > systems with cygwin 1.5 files are occasionally missed because of the > path length limitations so I really want to get a cygwin 1.7 setup > working. I'm in a situation somewhat similar to yours. Up to now I have been using the current stable Cygwin (v1.5) to test rsync as a possible backup solution. I have a home-baked rsync/--link-dest script that creates periodic snapshots of the Windows boxes on my LAN, and it hiccups noisily on long filenames, and on filenames with non-ASCII chars in them. I am considering trying out the next release of Cygwin (v1.7) for its supposed fixes to the v1.5 path-length and filename encoding limitations, but it would really suck if the --link-dest magic stopped working in v1.7. > This is the command that is being issued by dirvish to perform the backup. > > rsync -vrltH --delete -pgo --stats -z -D --numeric-ids --timeout=300 > --exclude-from=/srv/dirvish/srv-01/2009101610/exclude > --link-dest=/srv/dirvish/srv-01/2009101420/tree 10.2.35.241::data/ > /srv/dirvish/srv-01/2009101610/tree I'm not at all familiar with dirvish, but I've been using rsync quite a lot. I don't see anything out of the ordinary on the command line. It appears you are (or rather dirvish is) keeping successive backups on your Debian box under /srv/dirvish/srv-01//tree/. Probably a dumb question, but: Are you 100% certain that 2009101420/tree/ and 2009101610/tree/ are on the same filesystem? > Here is the checksums and the output of stat of two files on my Linux > box that I should have been linked together. No changes where made to > this file on the windows box between the first and second backups. [Snip the output of 'sha256sum' and 'stat' proving that the following files on the Debian box are essentially identical: `2009101420/tree/staff/Supply letter preschool.doc' `2009101610/tree/staff/Supply letter preschool.doc'] Okay, so the backed-up files appear to be identical in successive backups on the Debian (destination) side, including many attributes that one imagines rsync would check for differences (contents, name, size, type, access perms, ownerships, mod time). If --link-dest were working correctly, I would expect to see Links > 1 and the two files' Inode numbers to be the same, but neither is true (Links == 1, and the Inode numbers are different). Definitely proof that --link-dest is failing to work as intended. Clearly, rsync on your Debian box thinks that the source file 'staff/Supply letter preschool.doc' is somehow different from the existing file in the --link-dest directory. Just curious: What do 'sha256sum' and 'stat' say about that file on the Cygwin (source) side? > I have posted the output of 'cygcheck -s -v -r' here > (http://pastebin.com/m68d01c02). Could you post the contents of your rsync daemon's rsyncd.conf ? Are you using identical rsyncd.conf files in your 1.5 and 1.7 installations? > I would appreciate some help getting the --list-dest to work properly. > If you have some ideas please share. If you need more information to > help diagnose or find a solution please ask. Is --link-dest failing completely (i.e. no hardlinks created at all), or only partially (i.e. some unchanged files are hardlinked, while some are merely copied)? What version of rsync is running on the Debian box? > Thanks, > Chris Francy Regards, -SM -- -- 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
