[PATCH setup 0/2] List and offer to kill processes preventing a file from being written
I find it irritating to have to work out which process I need to stop when setup can't update a file, and setup not helping you find it doesn't really meet contemporary standards. So, loosely inspired by [1], a patch to list and offer to kill processes preventing a file from being written. This uses psapi.dll to find which out processes have a file loaded as a module. Note that this doesn't help when file isn't writeable because process has the file open exclusively, but there doesn't seem to be an interface to do this until the restart manager API introduced in Vista. This relies on the probably undocumented behaviour of /usr/bin/kill working with windows PIDs as well as cygwin PIDs, and the assumption those PID sets are disjoint. Ideally, I wanted to note if the process which had the file loaded was a service, and stop and restart the service. But this seems to be not straightforward to do, as setup doesn't have any visibility of the cygwin process tree, which is needed to find the cygrunsrv service process which is the parent of the process using the file, and thus the service name to stop and restart. [1] http://cygwin.com/ml/cygwin/2012-08/msg00444.html Jon TURNEY (2): Refactor ::run() so it's more generally useful List and offer to kill processes preventing a file from being written Makefile.am|4 +- install.cc | 152 +--- processlist.cc | 237 processlist.h | 41 ++ res.rc | 20 + resource.h |4 + script.cc | 33 + script.h |7 +- 8 files changed, 435 insertions(+), 63 deletions(-) create mode 100644 processlist.cc create mode 100644 processlist.h -- 1.7.9
[PATCH setup 1/2] Refactor ::run() so it's more generally useful
Move all the logging of the command it runs in
Move the formatting of the command line used for postinstall script running out
2013-02-01 Jon TURNEY jon.tur...@dronecode.org.uk
* script.cc (::run, Script::run): Move the formatting of the command
line used for postinstall script running out to Script::run. Move the
logging of the command and it's output into ::run.
* script.h: Add ::run() prototype.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
script.cc | 33 +++--
script.h |7 +--
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/script.cc b/script.cc
index 6663e8c..4bf0f09 100644
--- a/script.cc
+++ b/script.cc
@@ -196,10 +196,10 @@ OutputLog::out_to(std::ostream out)
SetFilePointer(_handle, 0, NULL, FILE_END);
}
-static int
-run (const char *sh, const char *args, const char *file, OutputLog file_out)
+int
+run (const char *cmdline)
{
- char cmdline[MAX_PATH];
+
STARTUPINFO si;
PROCESS_INFORMATION pi;
DWORD flags = CREATE_NEW_CONSOLE;
@@ -207,7 +207,11 @@ run (const char *sh, const char *args, const char *file,
OutputLog file_out)
BOOL inheritHandles = FALSE;
BOOL exitCodeValid = FALSE;
- sprintf (cmdline, %s %s \%s\, sh, args, file);
+ log(LOG_PLAIN) running: cmdline endLog;
+
+ char tmp_pat[] = /var/log/setup.log.runXXX;
+ OutputLog file_out = std::string (mktemp (tmp_pat));
+
memset (pi, 0, sizeof (pi));
memset (si, 0, sizeof (si));
si.cb = sizeof (si);
@@ -226,7 +230,7 @@ run (const char *sh, const char *args, const char *file,
OutputLog file_out)
flags = CREATE_NO_WINDOW; // Note: this is ignored on Win9x
}
- BOOL createSucceeded = CreateProcess (0, cmdline, 0, 0, inheritHandles,
+ BOOL createSucceeded = CreateProcess (0, (char *)cmdline, 0, 0,
inheritHandles,
flags, 0, get_root_dir ().c_str(),
si, pi);
@@ -237,6 +241,10 @@ run (const char *sh, const char *args, const char *file,
OutputLog file_out)
}
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
+
+ if (!file_out.isEmpty ())
+log(LOG_BABBLE) file_out endLog;
+
if (exitCodeValid)
return exitCode;
return -GetLastError();
@@ -268,24 +276,21 @@ Script::run() const
}
int retval;
- char tmp_pat[] = /var/log/setup.log.postinstallXXX;
- OutputLog file_out = std::string (mktemp (tmp_pat));
+ char cmdline[MAX_PATH];
+
if (sh.size() stricmp (extension(), .sh) == 0)
{
- log(LOG_PLAIN) running: sh --norc --noprofile \
scriptName \ endLog;
- retval = ::run (sh.c_str(), --norc --noprofile, scriptName.c_str(),
file_out);
+ sprintf (cmdline, %s %s \%s\, sh.c_str(), --norc --noprofile,
scriptName.c_str());
+ retval = ::run (cmdline);
}
else if (cmd stricmp (extension(), .bat) == 0)
{
- log(LOG_PLAIN) running: cmd /c \ windowsName \
endLog;
- retval = ::run (cmd, /c, windowsName.c_str(), file_out);
+ sprintf (cmdline, %s %s \%s\, cmd, /c, windowsName.c_str());
+ retval = ::run (cmdline);
}
else
return -ERROR_INVALID_DATA;
- if (!file_out.isEmpty ())
-log(LOG_BABBLE) file_out endLog;
-
if (retval)
log(LOG_PLAIN) abnormal exit: exit code= retval endLog;
diff --git a/script.h b/script.h
index 144fd71..abdd43e 100644
--- a/script.h
+++ b/script.h
@@ -14,7 +14,7 @@
*/
#ifndef SETUP_SCRIPT_H
#define SETUP_SCRIPT_H
-
+
/* Initialisation stuff for run_script: sh, cmd, CYGWINROOT and PATH */
void init_run_script ();
@@ -24,6 +24,9 @@ int try_run_script (const std::string dir,
const std::string fname,
const std::string ext);
+/* Run a command and capture it's output to the log */
+int run (const char *cmdline);
+
class Script {
public:
static bool isAScript (const std::string file);
@@ -32,7 +35,7 @@ public:
std::string fullName() const;
/* Run the script. If its suffix is .sh, and we have a Bourne shell, execute
it using sh. Otherwise, if the suffix is .bat, execute using cmd.exe (NT)
- or command.com (9x). Returns the exit status of the process, or
+ or command.com (9x). Returns the exit status of the process, or
negative error if any. */
int run() const;
bool operator == (const Script s) { return s.scriptName == scriptName; } ;
--
1.7.9
[PATCH setup 2/2] List and offer to kill processes preventing a file from being written
- Enumerate processes preventing a file from being written
- Replace the MessageBox reporting an in-use file with a DialogBox reporting the
in-use file and the processes which are using that file.
- Use /usr/bin/kill to kill processes which have files open, trying SIGTERM,
then SIGKILL, then TerminateProcess
2013-02-01 Jon TURNEY jon.tur...@dronecode.org.uk
* install.cc ( _custom_MessageBox): Remove custom message box.
(FileInuseDlgProc): Add file-in-use dialog box.
(installOne): Use processlist to list processes using a file, and
offer to kill them with the file-in-use dialog.
* res.rc (IDD_FILE_INUSE) : New dialog.
* resource.h (IDD_FILE_INUSE, IDC_FILE_INUSE_EDIT)
(IDC_FILE_INUSE_MSG, IDC_FILE_INUSE_HELP): Define corresponding
resource ID numbers.
* processlist.h: New file.
* processlist.cc: New file.
* Makefile.am (setup_LDADD): Add -lpsapi.
(setup_SOURCES): Add new files.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
Makefile.am|4 +-
install.cc | 152 +---
processlist.cc | 237
processlist.h | 41 ++
res.rc | 20 +
resource.h |4 +
6 files changed, 411 insertions(+), 47 deletions(-)
create mode 100644 processlist.cc
create mode 100644 processlist.h
diff --git a/Makefile.am b/Makefile.am
index 0f1498b..ddd19ed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -105,7 +105,7 @@ inilint_SOURCES = \
setup_LDADD = \
libgetopt++/libgetopt++.la -lgcrypt -lgpg-error \
- -lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -luuid -llzma -lbz2
-lz
+ -lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -lpsapi -luuid -llzma
-lbz2 -lz
setup_LDFLAGS = -mwindows -Wc,-static -static-libtool-libs
setup_SOURCES = \
AntiVirus.cc \
@@ -230,6 +230,8 @@ setup_SOURCES = \
postinstallresults.h \
prereq.cc \
prereq.h \
+ processlist.cc \
+ processlist.h \
proppage.cc \
proppage.h \
propsheet.cc \
diff --git a/install.cc b/install.cc
index 9d39f33..61333b7 100644
--- a/install.cc
+++ b/install.cc
@@ -63,6 +63,7 @@ static const char *cvsid = \n%%% $Id: install.cc,v 2.101
2011/07/25 14:36:24 jt
#include threebar.h
#include Exception.h
+#include processlist.h
using namespace std;
@@ -192,39 +193,61 @@ Installer::replaceOnRebootSucceeded (const std::string
fn, bool rebootneeded)
rebootneeded = true;
}
-#define MB_RETRYCONTINUE 7
-#if !defined(IDCONTINUE)
-#define IDCONTINUE IDCANCEL
-#endif
+typedef struct
+{
+ const char *msg;
+ const char *processlist;
+ int iteration;
+} FileInuseDlgData;
-static HHOOK hMsgBoxHook;
-LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam) {
- HWND hWnd;
- switch (nCode) {
-case HCBT_ACTIVATE:
- hWnd = (HWND)wParam;
- if (GetDlgItem(hWnd, IDCANCEL) != NULL)
- SetDlgItemText(hWnd, IDCANCEL, Continue);
- UnhookWindowsHookEx(hMsgBoxHook);
- }
- return CallNextHookEx(hMsgBoxHook, nCode, wParam, lParam);
-}
+static BOOL CALLBACK
+FileInuseDlgProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
+{
+ switch (uMsg)
+{
+case WM_INITDIALOG:
+ {
+FileInuseDlgData *dlg_data = (FileInuseDlgData *)lParam;
+
+SetDlgItemText(hwndDlg, IDC_FILE_INUSE_MSG, dlg_data-msg);
+SetDlgItemText(hwndDlg, IDC_FILE_INUSE_EDIT, dlg_data-processlist);
+
+switch (dlg_data-iteration)
+ {
+ case 0:
+break; // show the dialog the way it is in the resource
+
+ case 1:
+SetDlgItemText(hwndDlg, IDRETRY, Kill Processes);
+SetDlgItemText(hwndDlg, IDC_FILE_INUSE_HELP,
+ Select 'Kill' to kill Cygwin processes and retry,
or
+ select 'Continue' to go on anyway (you will need
to reboot).);
+break;
+
+ default:
+ case 2:
+SetDlgItemText(hwndDlg, IDRETRY, Kill Processes);
+SetDlgItemText(hwndDlg, IDC_FILE_INUSE_HELP,
+ Select 'Kill' to forcibly kill all processes and
retry, or
+ select 'Continue' to go on anyway (you will need
to reboot).);
+ }
+ }
+ return TRUE; // automatically set focus, please
-int _custom_MessageBox(HWND hWnd, LPCTSTR szText, LPCTSTR szCaption, UINT
uType) {
- int retval;
- bool retry_continue = (uType MB_TYPEMASK) == MB_RETRYCONTINUE;
- if (retry_continue) {
-uType = ~MB_TYPEMASK; uType |= MB_RETRYCANCEL;
-// Install a window hook, so we can intercept the message-box
-// creation, and customize it
-// Only install for THIS thread!!!
-hMsgBoxHook = SetWindowsHookEx(WH_CBT, CBTProc, NULL,
GetCurrentThreadId());
- }
- retval = MessageBox(hWnd, szText, szCaption, uType);
- // Intercept the return value
Re: [PATCH setup 0/2] List and offer to kill processes preventing a file from being written
Wow. Ambitious! On Tue, Feb 05, 2013 at 03:24:48PM +, Jon TURNEY wrote: I find it irritating to have to work out which process I need to stop when setup can't update a file, and setup not helping you find it doesn't really meet contemporary standards. So, loosely inspired by [1], a patch to list and offer to kill processes preventing a file from being written. This uses psapi.dll to find which out processes have a file loaded as a module. Note that this doesn't help when file isn't writeable because process has the file open exclusively, but there doesn't seem to be an interface to do this until the restart manager API introduced in Vista. This relies on the probably undocumented behaviour of /usr/bin/kill working with windows PIDs as well as cygwin PIDs, and the assumption those PID sets are disjoint. Why not just use TerminateProcess rather than Cygwin's /usr/bin/kill? FWIW, Cygwin's pids often == Windows pids. They are derived from the same pool. I really like this idea but I wonder if the use of psapi.dll will mean that setup-legacy.exe will be broken by that change since it is supposed to work on older platforms. And, I wonder if it really is time to stop offering the old 1.5.x binaries so we wouldn't have to worry about that. Other than that, I see some very minor formatting problems - you need to put spaces before opening parentheses for functions and macros. Ideally, I wanted to note if the process which had the file loaded was a service, and stop and restart the service. But this seems to be not straightforward to do, as setup doesn't have any visibility of the cygwin process tree, which is needed to find the cygrunsrv service process which is the parent of the process using the file, and thus the service name to stop and restart. Is there any way to determine if a process is running as a service? If so, I'd think that just telling someone they had to restart the service would be adequate. cgf
Re: [PATCH setup 0/2] List and offer to kill processes preventing a file from being written
On Feb 5 11:06, Christopher Faylor wrote: Wow. Ambitious! On Tue, Feb 05, 2013 at 03:24:48PM +, Jon TURNEY wrote: I find it irritating to have to work out which process I need to stop when setup can't update a file, and setup not helping you find it doesn't really meet contemporary standards. So, loosely inspired by [1], a patch to list and offer to kill processes preventing a file from being written. This uses psapi.dll to find which out processes have a file loaded as a module. Note that this doesn't help when file isn't writeable because process has the file open exclusively, but there doesn't seem to be an interface to do this until the restart manager API introduced in Vista. This relies on the probably undocumented behaviour of /usr/bin/kill working with windows PIDs as well as cygwin PIDs, and the assumption those PID sets are disjoint. Why not just use TerminateProcess rather than Cygwin's /usr/bin/kill? FWIW, Cygwin's pids often == Windows pids. They are derived from the same pool. I really like this idea but I wonder if the use of psapi.dll will mean that setup-legacy.exe will be broken by that change since it is supposed to work on older platforms. And, I wonder if it really is time to stop offering the old 1.5.x binaries so we wouldn't have to worry about that. +1. Other than that, I see some very minor formatting problems - you need to put spaces before opening parentheses for functions and macros. Ideally, I wanted to note if the process which had the file loaded was a service, and stop and restart the service. But this seems to be not straightforward to do, as setup doesn't have any visibility of the cygwin process tree, which is needed to find the cygrunsrv service process which is the parent of the process using the file, and thus the service name to stop and restart. Is there any way to determine if a process is running as a service? If so, I'd think that just telling someone they had to restart the service would be adequate. Starting with Vista you know a process is running as service if it's running in session 0. Other than that, if the process is called cygrunsrv, or if the process parent is called cygrunsrv, it's pretty likely that it's a service. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
nuke cygwin legacy?
Corinna +1'ed my suggestion that it was time to remove cygwin 1.5 support so I'm wondering if anyone has any objections to removing 1.5 from cygwin.com. I was going to suggest this a few months ago and mention that the Cygwin Time Machine was an alternative but it looks like that service is no longer available. So, as an alternative, we could advertise that the directory is going away on the main web page for a month before nuking it. cgf
Re: [PATCH setup 0/2] List and offer to kill processes preventing a file from being written
On 05/02/2013 16:16, Corinna Vinschen wrote: On Feb 5 11:06, Christopher Faylor wrote: Wow. Ambitious! On Tue, Feb 05, 2013 at 03:24:48PM +, Jon TURNEY wrote: I find it irritating to have to work out which process I need to stop when setup can't update a file, and setup not helping you find it doesn't really meet contemporary standards. So, loosely inspired by [1], a patch to list and offer to kill processes preventing a file from being written. This uses psapi.dll to find which out processes have a file loaded as a module. Note that this doesn't help when file isn't writeable because process has the file open exclusively, but there doesn't seem to be an interface to do this until the restart manager API introduced in Vista. This relies on the probably undocumented behaviour of /usr/bin/kill working with windows PIDs as well as cygwin PIDs, and the assumption those PID sets are disjoint. Why not just use TerminateProcess rather than Cygwin's /usr/bin/kill? Because sending SIGTERM gives the target process the opportunity to clean up? FWIW, Cygwin's pids often == Windows pids. They are derived from the same pool. I really like this idea but I wonder if the use of psapi.dll will mean that setup-legacy.exe will be broken by that change since it is supposed to work on older platforms. Yes, this probably doesn't work on older Windows versions (I have tested with W2K and that is fine), although information on API support in EOL'ed versions of Windows is hard to find... I guess this could be changed to use the autoload mechanism for the functions imported from psapi rather than linking with it. And, I wonder if it really is time to stop offering the old 1.5.x binaries so we wouldn't have to worry about that. +1. Other than that, I see some very minor formatting problems - you need to put spaces before opening parentheses for functions and macros. Ideally, I wanted to note if the process which had the file loaded was a service, and stop and restart the service. But this seems to be not straightforward to do, as setup doesn't have any visibility of the cygwin process tree, which is needed to find the cygrunsrv service process which is the parent of the process using the file, and thus the service name to stop and restart. Is there any way to determine if a process is running as a service? If so, I'd think that just telling someone they had to restart the service would be adequate. The problem is that (for example), sshd is not a service, it's a process started by an instance of cygrunsrv which is registered with the sshd service name and the sshd command line to run. I think that after finding that sshd is using some module we need to update, setup would need to navigate the Cygwin process tree to find the cygrunsrv process which is the parent of sshd to get the service name we would need to restart. I can't see how to do this in a purely windows application. Starting with Vista you know a process is running as service if it's running in session 0. Other than that, if the process is called cygrunsrv, or if the process parent is called cygrunsrv, it's pretty likely that it's a service.
Re: nuke cygwin legacy?
Am 05.02.2013 18:41, schrieb Christopher Faylor: Corinna +1'ed my suggestion that it was time to remove cygwin 1.5 support so I'm wondering if anyone has any objections to removing 1.5 from cygwin.com. I was going to suggest this a few months ago and mention that the Cygwin Time Machine was an alternative but it looks like that service is no longer available. So, as an alternative, we could advertise that the directory is going away on the main web page for a month before nuking it. cgf I had thought that support had stopped anyway, just keeping the files available. I used to run an old laptop with Windows ME until recently and maybe there's an ME or Windows 2000 surviving in some virtual machine... For owners of old hardware, there is also some Linux installations still available that fit into something like 20MB, so why not keep cygwin for download? Thomas
Re: nuke cygwin legacy?
On 2/5/2013 10:41, Christopher Faylor wrote: Corinna +1'ed my suggestion that it was time to remove cygwin 1.5 support so I'm wondering if anyone has any objections to removing 1.5 from cygwin.com. It seems to me that the sort of person who's still hanging onto a DOS-based version of Windows probably won't be watching this list, or to the cygwin.com home page. I propose making the deprecation a two-stage affair: 1. Move Cygwin 1.5 somewhere else, so that it doesn't get included in mirrors. 2. Point everything referring to the old mirror system at the new location, presumably a different subtree on sourceware.org. Then you can rely on the FTP/HTTP logs to determine how often people actually install these packages. There's a core assumption here, which is that download volumes have dropped enough that going back to a single download server is sane. If it turns out that download volume is unexpectedly high, though, well, that's answer enough, isn't it?
Re: nuke cygwin legacy?
On Tue, 5 Feb 2013 13:00:43 -0500, Christopher Faylor wrote: Because it is taking space on the web site and on sourceware.org and there is no good reason for it to be offered anymore. If there are virtual machines running ME then, if they haven't installed Cygwin 1.5 by now, there is no reason to assume that they will need it. Additionally, except for setup.exe, there have been no bug fixes or security fixes in 1.5 so we're offering buggy, insecure software on our site. Which, in and of itself, is reason to drop it. FWIW, I deleted legacy files from Ports a few months ago without complaint. Yaakov
Re: nuke cygwin legacy?
On Tue, Feb 05, 2013 at 07:57:58PM -0600, Yaakov wrote: On Tue, 5 Feb 2013 13:00:43 -0500, Christopher Faylor wrote: Because it is taking space on the web site and on sourceware.org and there is no good reason for it to be offered anymore. If there are virtual machines running ME then, if they haven't installed Cygwin 1.5 by now, there is no reason to assume that they will need it. Additionally, except for setup.exe, there have been no bug fixes or security fixes in 1.5 so we're offering buggy, insecure software on our site. Which, in and of itself, is reason to drop it. FWIW, I deleted legacy files from Ports a few months ago without complaint. Also, FWIW, it looks like setup-legacy was downloaded 14 times in the last year. I think that's a pretty good indication that it isn't very popular. cgf
Re: nuke cygwin legacy?
On Tue, 05 Feb 2013 20:56:42 +0100, Erwin Waterlander wrote: It doesn't matter that it is not secure. Yes, it does. IMHO it is irresponsible on our part to distribute unmaintained or knowingly vulnerable software, and it reflects badly on the Cygwin project. Yaakov
Fwd:
http://www.teicosgroup.com/gcr4rv.php?s=lf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog.64bit miscfuncs.cc ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-02-05 15:04:39 Modified files: winsup/cygwin : ChangeLog.64bit miscfuncs.cc mmap.cc winsup/cygwin/include/sys: dirent.h Log message: * miscfuncs.cc (RtlFillMemory): Declare. (RtlCopyMemory): Declare. (memset): Just call RtlFillMemory. (memcpy): Just call RtlCopyMemory. * mmap.cc (class mmap_record): Drop enforced packing. Reorder members to allow tight packing on 32 as well as on 64 bit. * include/sys/dirent.h: Don't enforced structure packing on x86_64. (__DIRENT_COOKIE): Use different value on 64 bit. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.82r2=1.1.2.83 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/miscfuncs.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.82.2.9r2=1.82.2.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mmap.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.177.2.6r2=1.177.2.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/sys/dirent.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.24.2.3r2=1.24.2.4
src/winsup/cygwin ChangeLog DevNotes cygtls.h ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-02-05 15:30:13 Modified files: winsup/cygwin : ChangeLog DevNotes cygtls.h dcrt0.cc exceptions.cc fhandler_socket.cc fhandler_termios.cc fhandler_tty.cc signal.cc sigproc.h winsup/cygwin/include/cygwin: signal.h Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.50r2=1.5939.2.51 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.20.2.5r2=1.20.2.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.80.2.14r2=1.80.2.15 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dcrt0.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.434.2.13r2=1.434.2.14 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.391.2.13r2=1.391.2.14 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.291.2.11r2=1.291.2.12 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_termios.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.101.2.4r2=1.101.2.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.268.2.8r2=1.268.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/signal.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.114.2.3r2=1.114.2.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.112.2.8r2=1.112.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/signal.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.19.4.6r2=1.19.4.7
src/winsup/cygwin ChangeLog.64bit pseudo-reloc.cc
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-02-05 19:54:00 Modified files: winsup/cygwin : ChangeLog.64bit pseudo-reloc.cc Log message: * fhandler_socket.cc (fhandler_socket::bind): Fix error code for empty filename. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.83r2=1.1.2.84 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pseudo-reloc.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.9.2.1r2=1.9.2.2
Re: non-blocking accept() can hang.
2013/2/5 Achim Gratz strom...@nexgo.de: Tanaka Akira akr at fsij.org writes: I found that non-blocking accept() can hang. [...] Have you tried this with the latest snapshot already? I think I use a released version, not a snapshot. (I updated Cygwin several days ago.) I attach cygcheck.out. -- Tanaka Akira cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Fwd:
http://www.cluae.com/vxeqjn.php?s=ot -- 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: non-blocking accept() can hang.
Greetings, Tanaka Akira! I found that non-blocking accept() can hang. [...] Have you tried this with the latest snapshot already? I think I use a released version, not a snapshot. (I updated Cygwin several days ago.) That was not a question, that was more of a suggestive hint, that this issue might be fixed in latest snapshot, and you would be better to try it out and see if that's true. I attach cygcheck.out. -- WBR, Andrey Repin (anrdae...@freemail.ru) 05.02.2013, 15:45 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
libgnutls 28 26 : attn mantainer
Volker I see the same lib in two packages: $ cygcheck -l libgnutls28 /usr/bin/cyggnutls-28.dll /usr/bin/cyggnutls-openssl-27.dll /usr/bin/cyggnutlsxx-28.dll $ cygcheck -l libgnutls26 /usr/bin/cyggnutls-26.dll /usr/bin/cyggnutls-extra-26.dll /usr/bin/cyggnutls-openssl-27.dll /usr/bin/cyggnutlsxx-27.dll Is this expected ? Regards Marco -- 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 Cygwin 1.7.17 + Bash and Grep...
I'm essentially trying to take the contents of one file, and use it as input for a grep command against another file, but I do not get any results, even though I know the 2nd file contains a match. In the one-liner below, I include an echo to confirm the output is in the variable that should be used with the grep command. [vmorales@D630-Vmorales ~]# for i in `cat file-a.txt`; do echo $i; grep $i file-b.txt; done alpha beta charlie delta echo [vmorales@D630-Vmorales ~]# grep charlie file-b.txt charlie,13 File-a.txt must be in DOS format. Try this. for i in `cat file-a.txt | d2u`; do echo $i; grep $i file-b.txt; done alpha beta charlie charlie,13 delta echo Roger -- 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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)
I am just reinstalling cygwin on a fresh install of XP on a rather old laptop with Avast as virus software. It is absolutely crawling at the texlive postinstallation stage - stuck showing 24-25% for at least half an hour now. I was about to give up but googled cygwin install hangs texlive-collection and was surprised to actually hit something so will leave it to run over night. Previous installs went a lot lot quicker. There is no /var/log/setup.log etc that I can see yet ( only an empty file setup.log.postinstallXa03208 in C:\cygwin\var\log). I can confirm kpsewhich.exe is taking most of the CPU. Jeremy -- View this message in context: http://cygwin.1069669.n5.nabble.com/Setup-2-774-texlive-postinstall-takes-10-hours-resending-due-to-cygwin-bounce-tp92260p95900.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)
On 2/5/2013 4:48 PM, jeremycraven wrote: I am just reinstalling cygwin on a fresh install of XP on a rather old laptop with Avast as virus software. It is absolutely crawling at the texlive postinstallation stage - stuck showing 24-25% for at least half an hour now. I was about to give up but googled cygwin install hangs texlive-collection and was surprised to actually hit something so will leave it to run over night. Previous installs went a lot lot quicker. There is no /var/log/setup.log etc that I can see yet ( only an empty file setup.log.postinstallXa03208 in C:\cygwin\var\log). I can confirm kpsewhich.exe is taking most of the CPU. Jeremy Hi Jeremy, just for curiosity, how many texlive-collections did you select for installation ? Regards Marco -- 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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)
On 2/5/2013 10:48 AM, jeremycraven wrote: I am just reinstalling cygwin on a fresh install of XP on a rather old laptop with Avast as virus software. It is absolutely crawling at the texlive postinstallation stage - stuck showing 24-25% for at least half an hour now. I was about to give up but googled cygwin install hangs texlive-collection and was surprised to actually hit something so will leave it to run over night. The texlive-collection-* postinstall scripts have to do a lot of work, and it takes time. You didn't say which of these packages you've installed. There are almost 100 of them, and most TeX users only need a few. See the announcement at http://cygwin.com/ml/cygwin-announce/2012-07/msg00013.html for some advice. Previous installs went a lot lot quicker. There is no /var/log/setup.log etc that I can see yet ( only an empty file setup.log.postinstallXa03208 in C:\cygwin\var\log). The log files will be available when setup.exe finishes. Please look at them and see if there's anything interesting to report. I can confirm kpsewhich.exe is taking most of the CPU. Not surprising. Ken -- 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: Promote sqlite 3.7.13-1 from test status?
Yaakov (Cygwin/X) writes: So you're saying that it is more important for Cygwin's sqlite3 to work with a Windows program than it is for it to work properly with other Cygwin libraries and programs? That doesn't sound very pragmatic to me. Software built for Cygwin should _always_ follow *NIX behaviour. I've had a few minutes to contemplate the SQLite source code. Aside from the different API used, it appears that the _real_ difference that's responsible for getting these disk I/O errors with the POSIX code is that for Windows (and Windows only) SQLite implements a retry-on-failure, complete with exponentially increasing backoff times. There's two ways to test that theory: one is to set the #DEFINE for the Windows code so that the retry code is not compiled in (or rendered ineffective): this should result in just about the same failures that were seen with the POSIX version. Secondly, to re-implement that retry-on-failure code in the POSIX section, which should get rid of these problems altogether. I'm a bit swamped with real work to do, so I wouldn't mind if someone could try the first option to confirm that it really delivers the same sort of interference with TortoiseSVN. If this is indeed the case, it would instill a greater confidence that the second option would actually solve the problem in the proper way. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem after updating a remote installation: Nothing happens
I have installed cygwin on a remote machine without network access by the following procedure. 1. I downloaded cygwin using the Download without install option, to a machine with network access. 2. I copied the contents of the Local Package Directory to the remote machine. 3. At that machine, installed cygwin with the Install from local directory option. Everything seemed to work out fine. My problem is now I find I need a package I didn't install the first time, in this case emacs. I went back to the first machine and 1. Re-ran the installer, selecting the Download without install option, and the emacs package. 2. Copied the change files in the Local Package Directory to the remote machine. 3. Re-ran the installer, the Install from local directory option, and selecting the install all options. It seemed to install OK (I got an error from about pango, which I think I fixed manually.) But when I type 'emacs' at the command line, nothing happens. No error, no warning, nothing. I am just returned to the command line again. How do I fix this? -- 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 Cygwin 1.7.17 + Bash and Grep...
Never heard of pspad, but I use Cygwin's dos2unix all the time for this kind of thing. Alan Thompson On Tue, Feb 5, 2013 at 6:49 AM, Gates, Roger roger.ga...@goodrich.com wrote: I'm essentially trying to take the contents of one file, and use it as input for a grep command against another file, but I do not get any results, even though I know the 2nd file contains a match. In the one-liner below, I include an echo to confirm the output is in the variable that should be used with the grep command. [vmorales@D630-Vmorales ~]# for i in `cat file-a.txt`; do echo $i; grep $i file-b.txt; done alpha beta charlie delta echo [vmorales@D630-Vmorales ~]# grep charlie file-b.txt charlie,13 File-a.txt must be in DOS format. Try this. for i in `cat file-a.txt | d2u`; do echo $i; grep $i file-b.txt; done alpha beta charlie charlie,13 delta echo Roger -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs fails on startup: cannot find cyggnutls-26.dll (with possible workaround)
On 2/5/2013 3:41 PM, Arnold Boothroyd wrote: After updating Cygwin on a Dell PC running Windows 7 (it may have been a year or two since the previous update, since setup.exe was outdated and therefore replaced with the current version), emacs (which had worked fine before) failed on startup, giving the error message /usr/bin/emacs-X11.exe: error while loading shared libraries: cyggnutls-26.dll: cannot open shared object file: No such file or directory The solution is to install the package libgnutls26, which should be a dependency of emacs but isn't. Could someone please add it? This is a packaging error on my part, due to the fact that the test version of emacs requires libgnutls28. Until the test version becomes the current version, I'll have to require both. Thanks for the report. Ken -- 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 after updating a remote installation: Nothing happens
On 2/5/2013 3:10 PM, Alan wrote: I have installed cygwin on a remote machine without network access by the following procedure. 1. I downloaded cygwin using the Download without install option, to a machine with network access. 2. I copied the contents of the Local Package Directory to the remote machine. 3. At that machine, installed cygwin with the Install from local directory option. Everything seemed to work out fine. My problem is now I find I need a package I didn't install the first time, in this case emacs. I went back to the first machine and 1. Re-ran the installer, selecting the Download without install option, and the emacs package. 2. Copied the change files in the Local Package Directory to the remote machine. 3. Re-ran the installer, the Install from local directory option, and selecting the install all options. It seemed to install OK (I got an error from about pango, which I think I fixed manually.) But when I type 'emacs' at the command line, nothing happens. No error, no warning, nothing. I am just returned to the command line again. Make sure you've installed all the dependencies of emacs, including libgnutls26. (See http://cygwin.com/ml/cygwin/2013-02/msg00059.html) Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs fails on startup: cannot find cyggnutls-26.dll (with possible workaround)
On Tue, 05 Feb 2013 17:04:30 -0500, Ken Brown wrote: The solution is to install the package libgnutls26, which should be a dependency of emacs but isn't. Could someone please add it? Done. Yaakov -- 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
