aboutsummaryrefslogtreecommitdiff
path: root/winsup/cygwin
diff options
context:
space:
mode:
Diffstat (limited to 'winsup/cygwin')
-rw-r--r--winsup/cygwin/ChangeLog5
-rw-r--r--winsup/cygwin/dir.cc21
-rw-r--r--winsup/cygwin/how-signals-work.txt18
3 files changed, 42 insertions, 2 deletions
diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 54fe58d..83d4a9b 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,8 @@
+Mon Sep 17 14:04:27 2001 Christopher Faylor <cgf@cygnus.com>
+
+ * syscalls.cc (rmdir): Set cwd to some other location if attempting to
+ rmdir current working directory.
+
Sun Sep 16 23:04:31 2001 Christopher Faylor <cgf@cygnus.com>
* dtable.h (not_open): Assure inline.
diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index ab2bfab..7b9b2d6 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -401,8 +401,29 @@ rmdir (const char *dir)
}
else
{
+ /* This kludge detects if we are attempting to remove the current working
+ directory. If so, we will move elsewhere to potentially allow the
+ rmdir to succeed. This means that cygwin's concept of the current working
+ directory != Windows concept but, hey, whaddaregonnado?
+ Note that this will not cause something like the following to work:
+ $ cd foo
+ $ rmdir .
+ since the shell will have foo "open" in the above case and so Windows will
+ not allow the deletion.
+ FIXME: A potential workaround for this is for cygwin apps to *never* call
+ SetCurrentDirectory. */
+ if (strcasematch (real_dir, cygheap->cwd.win32)
+ && !strcasematch ("c:\\", cygheap->cwd.win32))
+ {
+ DWORD err = GetLastError ();
+ if (!SetCurrentDirectory ("c:\\"))
+ SetLastError (err);
+ else
+ return rmdir (dir);
+ }
if (GetLastError() == ERROR_ACCESS_DENIED)
{
+
/* On 9X ERROR_ACCESS_DENIED is returned if you try to remove
a non-empty directory. */
if (wincap.access_denied_on_delete ())
diff --git a/winsup/cygwin/how-signals-work.txt b/winsup/cygwin/how-signals-work.txt
index ca1d8ef..710ce39 100644
--- a/winsup/cygwin/how-signals-work.txt
+++ b/winsup/cygwin/how-signals-work.txt
@@ -1,7 +1,5 @@
Copyright 2001 Red Hat Inc., Christopher Faylor
-[This is not yet complete. -cgf]
-
How do signals work?
On process startup, cygwin starts a secondary thread that deals with signals.
@@ -111,3 +109,19 @@ arrival is more or less maintained. It checks to see if a cygwin
routine has set a special "restore this errno on returning from a
signal" value and sets errno to this, if so. Finally, it restores all
of the register values that were in effect when sigdelayed was called.
+
+Ok, you thought I had forgotten about the 'pending' stuff didn't you?
+Well, if you can rewind up to the discussion of sig_handle we'll return
+to the situation where sigsave was currently active. In this case,
+setup_handler will set a "pending" flag, will reincrement the appropriate
+element of the above signal array, and will return 0 to indicate that
+the interrupt did not occur. Otherwise setup_handler returns 1.
+
+For pending signals, the theory is that the signal handler thread will
+be forced to be rerun by having some strategic cygwin function call
+sig_send with a __SIGFLUSH argument. This causes the signal handler
+to rescan the signal array looking for pending signals.
+
+This leads us to the sig_send function. This is the "client side" part
+of the signal manipulation process. sig_send is the low-level function
+called by a high level process like kill().