Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Apr 4 15:55, Takashi Yano wrote: Hi Corinna, On Fri, 3 Apr 2015 13:32:26 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Btw., we have a regression in the latest PTY code in terms of some native Windows tools. I noticed this with `icacls': To confirm this, I tried to build latest git version. However, I have found that cygwin1.dll built above does not work at all for me. With new cygwin1.dll, mintty keeps black screen, i.e. no prompt appears. It seems that this occurs after the following change. That should have been fixed by cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69. You have to rebuild Cygwin to make this change have an effect. Alternatively you could checkout f992ae6f4da99b6a200cfc146b96e8e921ca1e70 to ignore the ucontext stuff for now. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBHCgkkSXdY.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: subversion-1.8.13-1
This release addresses 3 security issues. CVE-2015-0202: Subversion HTTP servers with FSFS repositories are vulnerable to a remotely triggerable excessive memory use with certain REPORT requests. CVE-2015-0248: Subversion mod_dav_svn and svnserve are vulnerable to a remotely triggerable assertion DoS vulnerability for certain requests with dynamically evaluated revision numbers CVE-2015-0251: Subversion HTTP servers allow spoofing svn:author property values for new revisions For details see the advisories at: http://subversion.apache.org/security/CVE-2015-0202-advisory.txt http://subversion.apache.org/security/CVE-2015-0248-advisory.txt http://subversion.apache.org/security/CVE-2015-0251-advisory.txt NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.13/CHANGES for more details about the changes in 1.8.13. This release changes mod_dav_svn to no longer map requests to the local filesystem. Administrators of mod_dav_svn servers should read the section about this in the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org -- 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
Updated: subversion-1.8.13-1
This release addresses 3 security issues. CVE-2015-0202: Subversion HTTP servers with FSFS repositories are vulnerable to a remotely triggerable excessive memory use with certain REPORT requests. CVE-2015-0248: Subversion mod_dav_svn and svnserve are vulnerable to a remotely triggerable assertion DoS vulnerability for certain requests with dynamically evaluated revision numbers CVE-2015-0251: Subversion HTTP servers allow spoofing svn:author property values for new revisions For details see the advisories at: http://subversion.apache.org/security/CVE-2015-0202-advisory.txt http://subversion.apache.org/security/CVE-2015-0248-advisory.txt http://subversion.apache.org/security/CVE-2015-0251-advisory.txt NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.13/CHANGES for more details about the changes in 1.8.13. This release changes mod_dav_svn to no longer map requests to the local filesystem. Administrators of mod_dav_svn servers should read the section about this in the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org
Re: [ITP] Sendmail 8.14.9
Corinna Vinschen wrote: Daniel, On Feb 18 00:04, Corinna Vinschen wrote: On Feb 17 23:51, Christian Franke wrote: D. Boland wrote: Hi Corinna, Corinna Vinschen wrote: Only two smaller problems: - The mailq and newaliases symlinks in /usr/bin must not be part of the package, otherwise they potentially overwrite an existing configuration. They are created by sendmail-config anyway, if the user chooses to run the script. - Probably less important, but the other MTAs are installed into /usr/sbin, not into /usr/libexec. Fedora installs the sendmail binary as /usr/sbin/sendmail.sendmail, analog to postfix, which is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix. But that's not that important, as long as there's no collision. Other than that, I think the package is GTG. Thanks for the sharp eye. I'll remove the links. Another minor issue in the last line /etc/postinstall/sendmail.sh: chown SYSTEM:Administrators $UBINDIR/sendmail-config This does not work with all versions of Windows because the Administrators (S-1-5-32-544) group name may be localized. Indeed. That should use the gid 544 instead. I removed the just uploaded 32 bit sendmail package for now. For one thing, the 64 bit package is missing for some reason, the other is that you didn't take the above into account. The Administrators account is only called Administrators on certain language versions of Windows. On other language versions, the name Administrators is localized, for instance Administratoren on german versions. Please fix this before re-uploading. Thanks, Corinna I'm sorry, I didn't read the last post before uploading. I fixed it. Should I wait uploading until I have the 64-bit version ready? D.
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna, On Fri, 3 Apr 2015 13:32:26 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Btw., we have a regression in the latest PTY code in terms of some native Windows tools. I noticed this with `icacls': To confirm this, I tried to build latest git version. However, I have found that cygwin1.dll built above does not work at all for me. With new cygwin1.dll, mintty keeps black screen, i.e. no prompt appears. It seems that this occurs after the following change. Is replacing cygwin1.dll insufficient after this change? commit 28e457cd717d630d6ac13dba7b8f2a162156effb Author: Jon TURNEY jon.tur...@dronecode.org.uk Date: Mon Mar 30 20:31:13 2015 +0100 Provide ucontext to signal handlers Add ucontext.h header, defining ucontext_t and mcontext_t types. Provide sigaction sighandlers with a ucontext_t parameter, containing stack and context information. * include/sys/ucontext.h : New header. * include/ucontext.h : Ditto. * exceptions.cc (call_signal_handler): Provide ucontext_t parameter to signal handler function. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk -- Takashi Yano takashi.y...@nifty.ne.jp -- 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: [PATCH 2/3] Provide ucontext to signal handlers
On 04/04/2015 09:40, Corinna Vinschen wrote:
On Apr 3 23:09, Jon TURNEY wrote:
On 01/04/2015 15:22, Corinna Vinschen wrote:
On Apr 1 14:19, Jon TURNEY wrote:
Add ucontext.h header, defining ucontext_t and mcontext_t types.
Provide sigaction sighandlers with a ucontext_t parameter, containing stack and
context information.
* include/sys/ucontext.h : New header.
* include/ucontext.h : Ditto.
* exceptions.cc (call_signal_handler): Provide ucontext_t
parameter to signal handler function.
Patch is ok with a single change: Please add a FIXME? comment to:
else
RtlCaptureContext();
On second thought, calling RtlCaptureContext here is probably wrong.
Wrong and also dangerous.
This causes random crashes on x86.
It seems that RtlCaptureContext requires the framepointer of the calling
function in ebp, which it uses to report the rip and rsp of it's caller.
It also seems that gcc can decide to optimize the setting of the
framepointer away, irrespective of the fact that -fomit-frame-pointer is not
used when building exceptions.cc
If _cygtls::call_signal_handler() happens to get called with ebp pointing to
an invalid memory address, as seems to happen occasionally, we will fault in
RtlCaptureContext. (in all cases, the eip and ebp in the returned context
are incorrect)
I wrote the attached patch, which fakes a callframe for RtlCaptureContext to
avoid these possible crashes, but this needs more work to correctly report
eip and ebp
Maybe it's simpler than that? Looking into the GCC info pages, I found
this:
Starting with GCC version 4.6, the default setting (when not
optimizing for size) for 32-bit GNU/Linux x86 and 32-bit Darwin x86
targets has been changed to '-fomit-frame-pointer'. The default
can be reverted to '-fno-omit-frame-pointer' by configuring GCC
with the '--enable-frame-pointer' configure option.
Enabled at levels '-O', '-O2', '-O3', '-Os'.
Very good. I hadn't noticed that sentence and was just looking at the
-O also turns on -fomit-frame-pointer on machines where doing so does
not interfere with debugging.
So it seems adding -fomit-frame-pointer file by file in Makefile.in
(when building with -O2) is moot and only has an effect when building
unoptimized, otherwise all files are built with -fomit-frame-pointer
anyway.
So, what if we drop all the -fomit-frame-pointer from Makefile.in and
add an
exceptions_CFLAGS:=-fno-omit-frame-pointer
Does that help?
Yes, that seems to do the trick. Patch attached.
From cd8532832c92d10c1a3c1fb9ec705df0ea003e28 Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Sat, 4 Apr 2015 16:18:56 +0100
Subject: [PATCH] Compile exceptions.cc with -fno-omit-frame-pointer on x86
Selectively using -fomit-frame-pointer when -O is used doesn't make sense
anymore, apparently since gcc 4.6, -O implies -fomit-frame-pointer.
exceptions.cc must be compiled with -fno-omit-frame-pointer on x86, as it uses
RtlCaptureContext, which requires a frame pointer.
* Makefile.in : Remove setting -fomit-frame-pointer for compiling
various files, it is already the default. Set
-fno-omit-frame-pointer for exceptions.cc on x86.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
winsup/cygwin/ChangeLog | 6 +
winsup/cygwin/Makefile.in | 57 ---
2 files changed, 10 insertions(+), 53 deletions(-)
diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 5ada35d..a8f4e00 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,9 @@
+2015-04-04 Jon TURNEY jon.tur...@dronecode.org.uk
+
+ * Makefile.in : Remove setting -fomit-frame-pointer for compiling
+ various files, it is already the default. Set
+ -fno-omit-frame-pointer for exceptions.cc on x86.
+
2015-04-03 Takashi Yano takashi.y...@nifty.ne.jp
* fhandler_tty.cc (fhandler_pty_slave::read): Change calculation of
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index 9b82f0a..af9faf6 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -449,59 +449,10 @@ INSTOBJS:=automode.o binmode.o textmode.o textreadmode.o
TARGET_LIBS:=$(LIB_NAME) $(CYGWIN_START) $(GMON_START) $(LIBGMON_A) $(SUBLIBS)
$(INSTOBJS) $(EXTRALIBS)
ifneq ${filter -O%,$(CFLAGS)}
-cygheap_CFLAGS:=-fomit-frame-pointer
-cygthread_CFLAGS:=-fomit-frame-pointer
-cygtls_CFLAGS:=-fomit-frame-pointer
-cygwait_CFLAGS=-fomit-frame-pointer
-delqueue_CFLAGS:=-fomit-frame-pointer
-devices_CFLAGS:=-fomit-frame-pointer
-dir_CFLAGS:=-fomit-frame-pointer
-dlfcn_CFLAGS:=-fomit-frame-pointer
-dll_init_CFLAGS:=-fomit-frame-pointer
-dtable_CFLAGS:=-fomit-frame-pointer -fcheck-new
-fcntl_CFLAGS:=-fomit-frame-pointer
-fenv_CFLAGS:=-fomit-frame-pointer
-fhandler_CFLAGS:=-fomit-frame-pointer
Re: diff -r won't recurse
On 4/4/2015 3:27 PM, lemke...@t-online.de wrote: Clutching at straws (note the identical serial number, does it confuse Cygwin?): orion /usr/lib/csih/getVolInfo.exe /g Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 ... orion /usr/lib/csih/getVolInfo.exe /d Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 This was it. I changed the Volume Serial Number with a Sysinternals tool (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx) and after a reboot diff now recurses into the directories in question. Now is this a Cygwin bug or am I doing something terribly unsupported? The serial number is used by many tools to track the volumes that are crossed by reparse points to ensure that a loop does not occur. I suspect that in this case the tool is concluding that the reparse point is referring back to the same volume. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
AW: diff -r won't recurse
On Fri, 03 Apr 2015 16:50:09 +0200 Andrey Repin wrote: I've got a strange problem: diff -r /d /g won't recurse into the two directories. /d and /g are the roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other tools have no problems to walk the tree. strace doesn't give me a clue. Any ideas? Try /d/ /g/ ? Cygdrive automounts are implicit. Though, I'm unable to reproduce your case. $ ls -l /? ls: cannot access /?: No such file or directory $ diff -r /w /x Only in /w: $RECYCLE.BIN Only in /x: OS2 Only in /w: ssh-1Pr6UITz Only in /w: System Volume Information Only in /x: WINNT Yes, that's what I expected. And Erwin Waterlander suggested: there are no differences ;) I wish it were so. Nevertheless (-s lists identical files): orion diff -q -r -s /d/Program\ Files /g/Program\ Files orion But orion ls /d/Program\ Files /g/Program\ Files /d/Program Files: 7-ZipGPS-Track-Analyse-6 PlotSoft ... snipped. /g/Program Files: 7-ZipGPS-Track-Analyse-6 PlotSoft ... more snipped. I am sure this got something to do with this being on a cloned disk running in a XP virtual machine (vmplayer on Win 8,1). Thanks, Michael P.S. For some reason I can't subscribe properly to the list. It rejected my first request and following the instructions I received as a result wasn't successful. Profitieren Sie von der sicheren E-Mail-Übertragung Ihrer Daten mit einer kostenlosen E-Mail-Adresse der Telekom. www.t-online.de/email-kostenlos -- 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: Can I move Cygwin and Cygwin64 to a drive other than C: ?
Greetings, Eric Pement! Follow-up question for Corinna or anyone who might know the answer: On Apr 1 03:26, Robert Miles wrote: Can I move the entire Cygwin and Cygwin64 directory trees to one of the nearly empty drives, without losing the extra packages I've already downloaded and the files I've created? Robocopy allows to copy an entire Cygwin tree while keeping all permissions intact. I had good luck with something along the lines of robocopy C:\cygwin64 D:\cygwin64 /e /purge /z /copyall /sl . . . With an added comment that I *did* move Cygwin installations using robocopy and the above works for me. In an elevated shell. I recently needed to move a Cygwin installation, about 6 GB, to another drive accessible only on a network file system. Due to the number of files, copying everything would have taken a week or more, because everything slows down when the number of files increases. The solution I ultimately took was not the best. I compressed everything into a single *.7z (7-zip) archive, moved the single archive across the network, and uncompressed the *.7z archive on the target machine. Although the total time was much, much faster (maybe 5 or 6 hours, including 30 minutes to uncompress the archive), all my file permissions were set to the same value, regardless of what they had been previously, and any extended attributes were lost entirely. I didn't like it, but I had no realistic alternative. For future resource, what is the best way to archive a Cygwin installation into a single file, which will preserve all file properties and permissions, so that the archive can be transferred to another location? (For the sake of clarity, presume that Cygwin does NOT exist in the target location, so a non-Cygwin tool must be used to expand the archive.) About any sane modern archiving tool can read TAR archives. And most of them understand gz/xz/bz2 compression. You could have used any of that to unpack Cygwin to get a bootstrap environment, then use that environment to unpack the tar with all permisisons restored. Alternatively, RAR can add/restore access data. -- With best regards, Andrey Repin Saturday, April 4, 2015 21:48:51 Sorry for my terrible english... -- 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: diff -r won't recurse
On Sat, 04 Apr 2015 20:09:56 +0200 I wrote: On Fri, 03 Apr 2015 16:50:09 +0200 Andrey Repin wrote: I've got a strange problem: diff -r /d /g won't recurse into the two directories. /d and /g are the roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other tools have no problems to walk the tree. strace doesn't give me a clue. Any ideas? Try /d/ /g/ ? Cygdrive automounts are implicit. Though, I'm unable to reproduce your case. $ ls -l /? ls: cannot access /?: No such file or directory $ diff -r /w /x Only in /w: $RECYCLE.BIN Only in /x: OS2 Only in /w: ssh-1Pr6UITz Only in /w: System Volume Information Only in /x: WINNT Yes, that's what I expected. And Erwin Waterlander suggested: there are no differences ;) I wish it were so. Nevertheless (-s lists identical files): orion diff -q -r -s /d/Program\ Files /g/Program\ Files orion But orion ls /d/Program\ Files /g/Program\ Files /d/Program Files: 7-ZipGPS-Track-Analyse-6 PlotSoft ... snipped. /g/Program Files: 7-ZipGPS-Track-Analyse-6 PlotSoft ... more snipped. I am sure this got something to do with this being on a cloned disk running in a XP virtual machine (vmplayer on Win 8,1). Clutching at straws (note the identical serial number, does it confuse Cygwin?): orion /usr/lib/csih/getVolInfo.exe /g Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 Max Filenamelength : 255 Filesystemname : NTFS Flags : 700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE orion /usr/lib/csih/getVolInfo.exe /d Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 Max Filenamelength : 255 Filesystemname : NTFS Flags : 700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE Profitieren Sie von der sicheren E-Mail-Übertragung Ihrer Daten mit einer kostenlosen E-Mail-Adresse der Telekom. www.t-online.de/email-kostenlos -- 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: Can I move Cygwin and Cygwin64 to a drive other than C: ?
Follow-up question for Corinna or anyone who might know the answer: On Apr 1 03:26, Robert Miles wrote: Can I move the entire Cygwin and Cygwin64 directory trees to one of the nearly empty drives, without losing the extra packages I've already downloaded and the files I've created? Robocopy allows to copy an entire Cygwin tree while keeping all permissions intact. I had good luck with something along the lines of robocopy C:\cygwin64 D:\cygwin64 /e /purge /z /copyall /sl . . . With an added comment that I *did* move Cygwin installations using robocopy and the above works for me. In an elevated shell. I recently needed to move a Cygwin installation, about 6 GB, to another drive accessible only on a network file system. Due to the number of files, copying everything would have taken a week or more, because everything slows down when the number of files increases. The solution I ultimately took was not the best. I compressed everything into a single *.7z (7-zip) archive, moved the single archive across the network, and uncompressed the *.7z archive on the target machine. Although the total time was much, much faster (maybe 5 or 6 hours, including 30 minutes to uncompress the archive), all my file permissions were set to the same value, regardless of what they had been previously, and any extended attributes were lost entirely. I didn't like it, but I had no realistic alternative. For future resource, what is the best way to archive a Cygwin installation into a single file, which will preserve all file properties and permissions, so that the archive can be transferred to another location? (For the sake of clarity, presume that Cygwin does NOT exist in the target location, so a non-Cygwin tool must be used to expand the archive.) Thanks in advance. -- 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: Xorg server always starting up on DISPLAY 3.0
On Mon, Mar 30, 2015 at 8:17 AM, Jon TURNEY wrote: You have stale lock files /tmp/.X0-lock etc. Unfortunately startx(|win) is not as smart as it should be about detecting that the process owning the lock file is no longer running. That was indeed the problem. I didn't find them because my brain was stuck looking for them in /var/log/... Wouldn't it be nice if Cygwin cleaned up the /tmp directory each time the computer is re-booted? I don't know how that would work in real life, however. - Jim -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- 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: diff -r won't recurse
-Original-Nachricht- Betreff: Re: diff -r won't recurse Datum: Sat, 04 Apr 2015 20:29:40 +0200 Von: lemke...@t-online.de lemke...@t-online.de An: cygwin@cygwin.com On Sat, 04 Apr 2015 20:09:56 +0200 I wrote: On Fri, 03 Apr 2015 16:50:09 +0200 Andrey Repin wrote: I've got a strange problem: diff -r /d /g won't recurse into the two directories. /d and /g are the roots of two disks where /g is a clone (disk2vhd) of /d. ls -R and other tools have no problems to walk the tree. strace doesn't give me a clue. Any ideas? Yes, that's what I expected. And Erwin Waterlander suggested: there are no differences ;) I wish it were so. Nevertheless (-s lists identical files): orion diff -q -r -s /d/Program\ Files /g/Program\ Files orion But orion ls /d/Program\ Files /g/Program\ Files /d/Program Files: 7-ZipGPS-Track-Analyse-6 PlotSoft ... snipped. /g/Program Files: 7-ZipGPS-Track-Analyse-6 PlotSoft ... more snipped. I am sure this got something to do with this being on a cloned disk running in a XP virtual machine (vmplayer on Win 8,1). Clutching at straws (note the identical serial number, does it confuse Cygwin?): orion /usr/lib/csih/getVolInfo.exe /g Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 ... orion /usr/lib/csih/getVolInfo.exe /d Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 This was it. I changed the Volume Serial Number with a Sysinternals tool (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx) and after a reboot diff now recurses into the directories in question. Now is this a Cygwin bug or am I doing something terribly unsupported? Thanks, Michael Profitieren Sie von der sicheren E-Mail-Übertragung Ihrer Daten mit einer kostenlosen E-Mail-Adresse der Telekom. www.t-online.de/email-kostenlos -- 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: Can I move Cygwin and Cygwin64 to a drive other than C: ?
On 04.04.2015 21:52, Andrey Repin wrote: Greetings, Eric Pement! Follow-up question for Corinna or anyone who might know the answer: On Apr 1 03:26, Robert Miles wrote: Can I move the entire Cygwin and Cygwin64 directory trees to one of the nearly empty drives, without losing the extra packages I've already downloaded and the files I've created? Robocopy allows to copy an entire Cygwin tree while keeping all permissions intact. I had good luck with something along the lines of robocopy C:\cygwin64 D:\cygwin64 /e /purge /z /copyall /sl . . . With an added comment that I *did* move Cygwin installations using robocopy and the above works for me. In an elevated shell. I recently needed to move a Cygwin installation, about 6 GB, to another drive accessible only on a network file system. Due to the number of files, copying everything would have taken a week or more, because everything slows down when the number of files increases. The solution I ultimately took was not the best. I compressed everything into a single *.7z (7-zip) archive, moved the single archive across the network, and uncompressed the *.7z archive on the target machine. Although the total time was much, much faster (maybe 5 or 6 hours, including 30 minutes to uncompress the archive), all my file permissions were set to the same value, regardless of what they had been previously, and any extended attributes were lost entirely. I didn't like it, but I had no realistic alternative. For future resource, what is the best way to archive a Cygwin installation into a single file, which will preserve all file properties and permissions, so that the archive can be transferred to another location? (For the sake of clarity, presume that Cygwin does NOT exist in the target location, so a non-Cygwin tool must be used to expand the archive.) About any sane modern archiving tool can read TAR archives. And most of them understand gz/xz/bz2 compression. You could have used any of that to unpack Cygwin to get a bootstrap environment, then use that environment to unpack the tar with all permisisons restored. Agreed. I do this regularly (for a different reason), and all you need is a small subset of Cygwin that can support tar and gz/bz2/xz/whatever you use to compress the files. My subset is 21 megabytes when uncompressed; in your case it can be much smaller, as i also have wget and its dependencies, and i'm forming that subset automatically by unpacking packages (which means a lot of unneeded files are installed). You may need to run some kind of chown/chmod combo after unpacking that subset. Another interesting scenario is to use icacls to save ACLs of files, then use it on target machine to restore them. Also, you can just *install* a minimal set of Cygwin packages on the target machine normally. -- O ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: diff -r won't recurse
Greetings, lemke...@t-online.de! Clutching at straws (note the identical serial number, does it confuse Cygwin?): orion /usr/lib/csih/getVolInfo.exe /g Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 ... orion /usr/lib/csih/getVolInfo.exe /d Device Type: 7 Characteristics: 20 Volume Name: ND D (HDD) Serial Number : 3357258338 This was it. I changed the Volume Serial Number with a Sysinternals tool (https://technet.microsoft.com/en-us/sysinternals/bb897436.aspx) and after a reboot diff now recurses into the directories in question. Now is this a Cygwin bug or am I doing something terribly unsupported? Volume serial numbers are supposed to be unique... At least within one system installation. -- With best regards, Andrey Repin Sunday, April 5, 2015 02:47:47 Sorry for my terrible english... -- 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
