Mail Archives: cygwin/2006/12/12/09:16:11
On Dec 12 08:58, Igor Peshansky wrote:
> On Tue, 12 Dec 2006, Michael Schaap wrote:
> > I went down the list of snapshots, and it looks like this was introduced
> > some time in between 2006-11-27 and 2006-11-30.
>
> I just looked at the ChangeLog between those two snapshots. The following
> looks like the culprit change:
>
> 2006-11-29 Corinna Vinschen <...>
>
> * path.cc [snip]
> (cwdstuff::init): Initialize cygheap->cwd with current working
> directory. Change to windows_system_directory afterwards.
>
> With that change, any use of non-Cygwin calls, e.g., GetCurrentDirectory,
> or ShellExecute (which calls GetCurrentDirectory under the covers, it
> seems) will produce the problem you're seeing (Windows system directory as
> the current directory).
>
> So it looks like you ought to call cygwin_internal(CW_SYNC_WINENV) after
> all, as it syncs more than the environment variables...
Right. The idea is that Cygwin applications are POSIX applications
which use POSIX calls. If you require Windows calls in your Cygwin
application, you should always call cygwin_internal(CW_SYNC_WINENV)
before doing the Windows calls (if they are working directory related,
yada yada yada).
The idea behind this change (always having system32 as cwd) is this:
POSIX allows to remove a directory, even if this directory is the
current working directory of the process itself, or of any other
process. This doesn't work on Windows, because every win32 process has
an open handle to its cwd. Since Cygwin processes are not actually
anymore in the directory which is their cwd, they don't have an open
handle on this dir. So the dir is removable now, provided there isn't a
native win32 process hanging around in this directory. This change was
a preparation for the patch which also allows to remove local files
which have an open handle (they are actually now moved to the recycle
bin and marked for "delete on close".
When using cygwin_internal(CW_SYNC_WINENV), Cygwin doesn't only copy the
environment, it also changes into the actual cwd and keeps Cygwin cwd
and native cwd in sync. This is also propagated to child processes.
Naturally, this process and its children are blocking the cwd from now
on, until all these processes exited.
A cygwin process not calling native Windows calls never need to call
cygwin_internal(CW_SYNC_WINENV). fork/exec gets it right automatically,
even if the child process is a native win32 process.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -