newlib-cygwin/winsup/doc/faq-using.xml

<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.5//EN"
		"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">

<qandadiv id="faq.using">
<title>Using Cygwin</title>

<!-- faq-problems.xml -->
<qandaentry id="faq.using.missing-dlls">
<question><para>Why can't my application locate cygncurses-8.dll?  or cygintl-3.dll?  or cygreadline6.dll?  or ...?</para></question>
<answer>

<para>Well, something has gone wrong somehow...
</para>
<para>To repair the damage, you must run Cygwin Setup again, and re-install the
package which provides the missing DLL package.
</para>
<para>If you already installed the package at one point, Cygwin Setup won't
show the option to install the package by default.  In the
``Select packages to install'' dialog, click on the <literal>Full/Part</literal>
button.  This lists all packages, even those that are already
installed.  Scroll down to locate the missing package, for instance
<literal>libncurses8</literal>.  Click on the ``cycle'' glyph until it says
``Reinstall''.  Continue with the installation.
</para>
<para>For a detailed explanation of the general problem, and how to extend
it to other missing DLLs and identify their containing packages, see
<ulink url="https://cygwin.com/ml/cygwin/2002-01/msg01619.html"/>.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.startup-slow">
<question><para>Starting a new terminal window is slow. What's going on?</para></question>
<answer>

<para>There are many possible causes for this.</para>

<para>If your terminal windows suddenly began starting slowly after a
Cygwin upgrade, it may indicate issues in the authentication
setup.</para>

<para>For almost all its lifetime, Cygwin has used Unix-like
<filename>/etc/passwd</filename> and <filename>/etc/group</filename>
files to mirror the contents of the Windows SAM and AD databases.
Although these files can still be used, since Cygwin 1.7.34, new
installations now use the SAM/AD databases directly.</para>

<para>To switch to the new method, move these two files out of the way
and restart the Cygwin terminal. That runs Cygwin in its new default
mode.</para>

<para>If you are on a system that isn't using AD domain logins, this
makes Cygwin use the native Windows SAM database directly, which may be
faster than the old method involving <filename>/etc/passwd</filename>
and such. At worst, it will only be a bit slower. (The speed difference
you see depends on which benchmark you run.) For the AD case, it can be
slower than the old method, since it is trading a local file read for a
network request. Version 1.7.35 will reduce the number of AD server
requests the DLL makes relative to 1.7.34, with the consequence that you
will now have to alter <filename>/etc/nsswitch.conf</filename> in order
to change your Cygwin home directory, instead of being able to change it
from the AD configuration.</para>

<para>If you are still experiencing very slow shell startups, there are
a number of other things you can look into:</para>

<orderedlist>
  <listitem>
    <para>One common cause of slow Cygwin Terminal starts is a bad DNS
    setup. This particularly affects AD clients, but there may be other
    things in your Cygwin startup that depend on getting fast answers
    back from a network server.</para>
    
    <para>Keep in mind that this may affect Cygwin even when the domain
    controller is on the same machine as Cygwin, or is on a nearby
    server. A bad DNS server IP can cause long delays while the local
    TCP/IP stack times out on a connection to a server that simply isn't
    there, for example.</para>
  </listitem>

  <listitem>
    <para>Another cause for AD client system is slow DC replies,
    commonly observed in configurations with remote DC access. The
    Cygwin DLL queries information about every group you're in to
    populate the local cache on startup. You may speed up this process a
    little by caching your own information in local files. Run these
    commands in a Cygwin terminal with write access to
    <filename>/etc</filename>:</para>

    <screen>getent passwd $(id -u) > /etc/passwd
getent group $(id -G) > /etc/group</screen>

    <para>Also, set <filename>/etc/nsswitch.conf</filename> as
    follows:</para>

    <screen>passwd: files db
group:  files db</screen>

    <para>This will limit the need for Cygwin to contact the AD domain
    controller (DC) while still allowing for additional information to
    be retrieved from DC, such as when listing remote
    directories.</para>
  </listitem>

  <listitem>
    <para>Either in addition to the previous item or instead of it, you
    can run <ulink
    url="https://cygwin.com/cygwin-ug-net/using-cygserver.html"><command>cygserver</command></ulink>
    as a local caching service to speed up DC requests.</para>

    <para>Cygwin programs will check with <command>cygserver</command>
    before trying to query the DC directly.</para>
  </listitem>

  <listitem>
    <para>A less preferable option is to create a static read-only cache
    of the authentication data. This is the old-fashioned method of
    making Cygwin integrate with AD, the only method available in
    releases before 1.7.34. To do this, run <command>mkpasswd</command>
    and <command>mkgroup</command>, then put the following into
    <filename>/etc/nsswitch.conf</filename> to make Cygwin treat these
    files as the only sources of user and group information:</para>

    <screen>passwd: files
group:  files</screen>

    <para>By leaving out the <computeroutput>db</computeroutput> option,
    we are telling the Cygwin DLL not to even try to do AD lookups. If
    your AD servers are slow, this local cache will speed things up. The
    downside is that you open yourself up to the <ulink
    url="http://en.wikipedia.org/wiki/Cache_(computing)">stale cache
    problem</ulink>: any time the AD databases change, your local cache
    will go out of date until you update the files manually.</para>
  </listitem>
</orderedlist>

<para>If none of the above helps, the best troubleshooting method is to
run your startup scripts in debug mode. Right-click your Cygwin Terminal
icon, go to Properties, and edit the command. It should be something
like <command>C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico
-</command>.  Assuming you are using Bash for your login shell, change
it to <command>C:\cygwin\bin\mintty /bin/bash -lx</command> then try
running Cygwin Terminal again. The <option>-x</option> option tells Bash
to write every command it runs to the terminal before launching it. If
the terminal immediately starts filling with lines of text but then
pauses, the line where the output paused is your clue as to what's going
on. The Cygwin DLL proper probably isn't the cause of the slowdown in
this case, since those delays happen before the first line of text
appears in the terminal.</para>

</answer></qandaentry>

<qandaentry id="faq.using.slow">
<question><para>Why is Cygwin suddenly <emphasis>so</emphasis> slow?</para></question>
<answer>

<para>If suddenly <emphasis>every</emphasis> command takes a
<emphasis>very</emphasis> long time, then something is probably attempting to 
access a network share.  You may have the obsolete <literal>//c</literal>
notation in your PATH or startup files.  Using <literal>//c</literal> means
to contact the <emphasis>network server</emphasis> <literal>c</literal>, which
will slow things down tremendously if it does not exist.  
</para>
</answer></qandaentry>

<qandaentry id="faq.using.shares">
<question><para>Why can't my services access network shares?</para></question>
<answer>

<para>If your service is one of those which switch the user context
(sshd, inetd, etc), then it depends on the method used to switch to
another user.  This problem as well as its solution is described in
detail in the Cygwin User's Guide, see
<ulink url="https://cygwin.com/cygwin-ug-net/ntsec.html"/>.
</para>
<para>Workarounds include using public network share that does not require
authentication (for non-critical files), providing your password to a
<command>net use</command> command, or running the service as your own
user with <literal>cygrunsrv -u</literal> (see
<literal>/usr/share/doc/Cygwin/cygrunsrv.README</literal> for more
information).
</para>
</answer></qandaentry>

<qandaentry id="faq.using.path">
<question><para>How should I set my PATH?</para></question>
<answer>

<para>This is done for you in the file /etc/profile, which is sourced by bash
when you start it from the Desktop or Start Menu shortcut, created by
<literal>setup.exe</literal>.  The line is
</para>
<screen>
	PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
</screen>

<para>Effectively, this <emphasis role='bold'>prepends</emphasis> /usr/local/bin and /usr/bin to your
Windows system path.  If you choose to reset your PATH, say in
$HOME/.bashrc, or by editing etc/profile directly, then you should
follow this rule.  You <emphasis role='bold'>must</emphasis> have <literal>/usr/bin</literal> in your PATH
<emphasis role='bold'>before</emphasis> any Windows system directories.  (And you must not omit
the Windows system directories!)  Otherwise you will likely encounter
all sorts of problems running Cygwin applications.
</para>
<para>If you're using another shell than bash (say, tcsh), the mechanism
is the same, just the names of the login scripts are different.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.not-found">
<question><para>Bash (or another shell) says "command not found", but it's right there!</para></question>
<answer>

<para>If you compile a program, you might find that you can't run it:
</para>
<screen>
	bash$ gcc -o hello hello.c
        bash$ hello
        bash: hello: command not found
</screen>

<para>Unlike the Windows default behaviour, Unix shells like bash do not look for programs in <literal>.</literal> (the current
directory) by default.  You can add <literal>.</literal> to your PATH (see above),
but this is not recommended (at least on UNIX) for security reasons.
Just tell bash where to find it, when you type it on the command line:
</para>
<screen>
	bash$ gcc -o hello hello.c
        bash$ ./hello
        Hello World!
</screen>

</answer></qandaentry>

<qandaentry id="faq.using.converting-paths">
<question><para>How do I convert between Windows and UNIX paths?</para></question>
<answer>

<para>Use the 'cygpath' utility.  Type '<literal>cygpath --help</literal>' for
information.  For example (on my installation):
<screen>
	bash$ cygpath --windows ~/.bashrc
        D:\starksb\.bashrc
        bash$ cygpath --unix C:/cygwin/bin/ls.exe
        /usr/bin/ls.exe
        bash$ cygpath --unix C:\\cygwin\\bin\\ls.exe
        /usr/bin/ls.exe
</screen>
Note that bash interprets the backslash '\' as an escape character, so
you must type it twice in the bash shell if you want it to be recognized
as such.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.bashrc">
<question><para>Why doesn't bash read my .bashrc file on startup?</para></question>
<answer>

<para>Your .bashrc is read from your home directory specified by the HOME
environment variable.  It uses /.bashrc if HOME is not set.  So you need
to set HOME (and the home dir in your passwd account information) correctly.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.bash-insensitive">
<question><para>How can I get bash filename completion to be case insensitive?</para></question>
<answer>

<para>Add the following to your <literal>~/.bashrc</literal> file:
</para>
<screen>
	shopt -s nocaseglob
</screen>

<para>and add the following to your <literal>~/.inputrc</literal> file:
</para>
<screen>
	set completion-ignore-case on
</screen>

</answer></qandaentry>

<qandaentry id="faq.using.filename-spaces">
<question><para>Can I use paths/filenames containing spaces in them?</para></question>
<answer>

<para>Cygwin does support spaces in filenames and paths.  That said, some
utilities that use the library may not, since files don't typically
contain spaces in Unix.  If you stumble into problems with this, you
will need to either fix the utilities or stop using spaces in filenames
used by Cygwin tools.
</para>
<para>In particular, bash interprets space as a word separator.  You would have
to quote a filename containing spaces, or escape the space character.
For example:
<screen>
	bash-2.03$ cd '/cygdrive/c/Program Files'
</screen>
or
<screen>
	bash-2.03$ cd /cygdrive/c/Program\ Files
</screen>
</para>
</answer></qandaentry>

<qandaentry id="faq.using.shortcuts">
<question><para>Why can't I cd into a shortcut to a directory?</para></question>
<answer>

<para>Cygwin does not follow MS Windows Explorer Shortcuts
(*.lnk files).  It sees a shortcut as a regular file and this you
cannot "cd" into it.
</para>
<para>Cygwin is also capable to create POSIX symlinks as Windows shortcuts 
(see the CYGWIN environment variable option "winsymlinks"), but these
shortcuts are different from shortcuts created by native Windows
applications.  Windows applications can usually make use of Cygwin
shortcuts but not vice versa.  This is by choice.  The reason is that
Windows shortcuts may contain a bunch of extra information which would
get lost, if, for example, Cygwin tar archives and extracts them as
symlinks.
</para>
<para>Changing a Cygwin shortcut in Windows Explorer usually changes a Cygwin
shortcut into a Windows native shortcut.  Afterwards, Cygwin will not
recognize it as symlink anymore.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.find">
<question><para>I'm having basic problems with find.  Why?</para></question>
<answer>

<para>Make sure you are using the find that came with Cygwin and that you
aren't picking up the Win32 find command instead.  You can verify that
you are getting the right one by doing a "type find" in bash.
</para>
<para>If the path argument to find, including current directory (default), is
itself a symbolic link, then find will not traverse it unless you
specify the <literal>-follow</literal> option.  This behavior is different than most
other UNIX implementations, but is not likely to change.
</para>
<para>If find does not seem to be producing enough results, or seems to be
missing out some directories, you may be experiencing a problem with one
of find's optimisations.  The absence of <literal>.</literal> and <literal>..</literal>
directories on some filesystems, such as DVD-R UDF, can confuse find.
See the documentation for the option <literal>-noleaf</literal> in the man page.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.su">
<question><para>Why doesn't <literal>su</literal> work?</para></question>
<answer>

<para>The <literal>su</literal> command has been in and out of Cygwin distributions, but
it has not been ported to Cygwin and has never worked.  It is
currently installed as part of the sh-utils, but again, it does not work.
</para>
<para>You should rather install <literal>sshd</literal> and use
<literal>ssh username@localhost</literal> as a <literal>su</literal>
replacement.
</para>
<para>For some technical background into why <literal>su</literal> doesn't
work, read
<ulink url="https://www.cygwin.com/ml/cygwin/2003-06/msg00897.html"/> and
related messages.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.man">
<question><para>Why doesn't <literal>man -k</literal>,
<literal>apropos</literal> or <literal>whatis</literal> work?</para></question>
<answer>

<para>Before you can use <literal>man -k</literal>, <literal>apropos</literal>
or <literal>whatis</literal>, you
must create the whatis database.  Just run the command
</para>
<screen>
	mandb
</screen>

<para>(it may take a few minutes to complete).
</para>
</answer></qandaentry>

<qandaentry id="faq.using.chmod">
<question><para>Why doesn't <literal>chmod</literal> work?</para></question>
<answer>

<para>If you're using FAT32 instead of NTFS, <literal>chmod</literal> 
will fail since FAT32 does not provide any permission information.
You should really consider converting the drive to NTFS with
<literal>CONVERT.EXE</literal>.  FAT and FAT32 are barely good enough
for memory cards or USB sticks to exchange pictures...
</para>
<para>For other cases, understand that Cygwin attempts to show UNIX 
permissions based on the security features of Windows, so the Windows 
ACLs are likely the source of your problem.  See the Cygwin User's 
Guide at <ulink url="https://cygwin.com/cygwin-ug-net/ntsec.html"/>
for more information on how Cygwin maps Windows permissions.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.shell-scripts">
<question><para>Why doesn't my shell script work?</para></question>
<answer>

<para>There are two basic problems you might run into.  One is the fact that
<command>/bin/sh</command> is really <command>bash</command>.
It could be missing some features you might expect in
<command>/bin/sh</command>, if you are used to <command>/bin/sh</command>
actually being <command>zsh</command> (MacOS X "Panther") or
<command>ksh</command> (Tru64).  
</para>

<para>Or, it could be a permission problem, and Cygwin doesn't understand
that your script is executable.  On NTFS or NFS just make the script
executable using <literal>chmod +x</literal>.  However,
<literal>chmod</literal> may not work due to restrictions of the
filesystem (see FAQ entry above).  In this case Cygwin must read the
contents of files to determine if they are executable.  If your script
does not start with
</para>
<screen>
	#! /bin/sh
</screen>

<para>(or any path to a script interpreter, it does not have to be /bin/sh)
then Cygwin will not know it is an executable script.  The Bourne shell
idiom
</para>
<screen>
	:
	# This is the 2nd line, assume processing by /bin/sh
</screen>

<para>also works.
</para>
<para>Note that you can use the filesystem flag <literal>cygexec</literal> in
<filename>/etc/fstab</filename> to force Cygwin to treat all files
under the mount point as executable.  This can be used for individual
files as well as directories.  Then Cygwin will not bother to read files
to determine whether they are executable.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.printing">
<question><para>How do I print under Cygwin?</para></question>
<answer>

<para>lpr is available in the cygutils package.  Some <ulink url="https://cygwin.com/ml/cygwin/2008-05/msg00123.html">usage hints</ulink> are available courtesy of Rodrigo Medina.
</para>
<para>Jason Tishler has written a couple of messages that explain how to use
a2ps (for nicely formatted text in PostScript) and ghostscript (to print
PostScript files on non-PostScript Windows printers).  Start at
<ulink url="https://cygwin.com/ml/cygwin/2001-04/msg00657.html"/>.  Note that
these are old mails and <command>a2ps</command> as well as
<command>file</command> are long available as part of the Cygwin distribution.
</para>
<para>Alternatively, you can use the Windows <command>print</command>
command.  Type
</para>
<screen>
	bash$ print /\?
</screen>

<para>for usage instructions (note the <literal>?</literal> must be escaped
from the shell).
</para>
<para>Finally, you can simply <command>cat</command> the file to the printer's share name:
</para>
<screen>
	bash$ cat myfile &gt; //host/printer
</screen>

<para>You may need to press the formfeed button on your printer or append the
formfeed character to your file.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.unicode">
<question><para>Why don't international (Unicode) characters work?</para></question>
<answer>

<para>Internationalization is a complex issue. The short answer is that
Cygwin relies on the setting of the setting of LANG/LC_xxx environment
variables. The long answer can be found in the User's Guide in the
section <ulink url="https://cygwin.com/cygwin-ug-net/setup-locale.html">Internationalization</ulink>
</para>

<para> Cygwin uses UTF-8 by default.  To use a different character set, you
need to set the LC_ALL, LC_CTYPE or LANG environment variables.</para>
</answer></qandaentry>

<qandaentry id="faq.using.weirdchars">
<question><para>My application prints international characters but I only
see gray boxes</para></question>
<answer>
<para>In the case of Cygwin programs, this likely means that the
character set as determined by the LC_ALL, LC_CTYPE or LANG environment
variables does not match the one set on the Text page of the Cygwin Terminal's
options.  Setting the locale in the terminal's options will set the LANG
variable accordingly.</para>
<para>Non-Cygwin programs in the Cygwin Terminal do not usually take
heed of the locale environment variables.  Instead, they often use the
so-called console codepage, which can be determined with the command
<command>cmd /c chcp</command> followed by the appropriate Windows
codepage number.  The codepage number for Cygwin's default UTF-8 character
set is 65001.</para>
</answer></qandaentry>

<qandaentry id="faq.using.multiple-copies">
<question><para>Is it OK to have multiple copies of the DLL?</para></question>
<answer>
<para>Yes, as long as they are used in strictly separated installations.</para>
<para>The Cygwin DLL has to handle various sharing situations between
multiple processes.  It has to keep a process table.  It has to maintain
a mount table which is based on the installation path of the Cygwin DLL.</para>
<para>For that reason, the Cygwin DLL maintains shared resources based on
a hash value created from its own installation path.  Each Cygwin DLL
on the machine constitutes a Cygwin installation, with the directory
the Cygwin DLL resides in treated as "/bin", the parent directory as "/".
</para>
<para>Therefore, you can install two or more separate Cygwin distros on
a single machine.  Each of these installations use their own Cygwin DLL,
and they don't share the default POSIX paths, nor process tables, nor
any other shared resource used to maintain the installation.</para>
<para>However, a clean separation requires that you don't try to run
executables of one Cygwin installation from processes running in another
Cygwin installation.  This may or may not work, but the chances that the
result is not what you expect are pretty high.</para>
<para>If you get the error "shared region is corrupted" or "shared region
version mismatch" it means you have multiple versions of cygwin1.dll
running at the same time which conflict with each other.  Apart from
mixing executables of different Cygwin installations, this could also happen
if you have one a single Cygwin installation, for example, if you update the
Cygwin package without exiting <emphasis>all</emphasis> Cygwin apps (including
services like sshd) beforehand.</para>
<para>The only DLL that is sanctioned by the Cygwin project is the one that
you get by running <ulink url="https://cygwin.com/install.html">setup-x86.exe or setup-x86_64.exe</ulink>,
installed in a directory controlled by this program.  If you have other
versions on your system and desire help from the cygwin project, you should
delete or rename all DLLs that are not installed by
<filename>setup.exe</filename>.
</para>
<para>If you're trying to find multiple versions of the DLL that are causing
this problem, reboot first, in case DLLs still loaded in memory are the
cause.  Then use the Windows System find utility to search your whole
machine, not just components in your PATH (as 'type' would do) or
cygwin-mounted filesystems (as Cygwin 'find' would do).
</para>
</answer></qandaentry>

<qandaentry id="faq.using.third-party.multiple-copies">
<question><para>
I read the above but I want to bundle Cygwin with a product, and ship it
to customer sites.  How can I do this without conflicting with any Cygwin
installed by the user?
</para></question>
<answer><para>
Usually, if you keep your installation separate, nothing bad should happen.
However, for the user's convenience, and to avoid potential problems which
still can occur, consider to integrate your product with an already existing
Cygwin installation on the user's machine, or, if there is none, consider
to install the official Cygwin distro on behalf of the user and integrate
your tools from there.  (If you write a tool to make this easy, consider
contributing it for others to use)
</para></answer></qandaentry>

<qandaentry id="faq.using.bundling-cygwin">
<question><para>
Can I bundle Cygwin with my product for free?
</para></question>
<answer><para>
Starting with Cygwin version 2.5.2, which is LGPL licensed, yes, albeit
it's not recommended for interoperability reasons.</para>

<para>Cygwin versions prior to 2.5.2 were GPL licensed.
If you choose to distribute an older cygwin1.dll, you must be willing to
distribute the exact source code used to build that copy of cygwin1.dll
as per the terms of the GPL.  If you ship applications that link with
older cygwin1.dll, you must provide those applications' source code
under a GPL-compatible license.
</para></answer></qandaentry>

<qandaentry id="faq.using.older-cygwin-conflict">
<question><para>
But doesn't that mean that if some application installs an older Cygwin
DLL on top of a newer DLL, my application will break?
</para></question>
<answer><para>
It depends on what you mean by "break".  If the application installs a
version of the Cygwin DLL in another location than Cygwin's /bin
directory then the rules in
<xref linkend="faq.using.third-party.multiple-copies"></xref> apply. 
If the application installs an older version of the DLL in /bin then you
should complain loudly to the application provider.
</para><para>
Remember that the Cygwin DLL strives to be backwards compatible so a
newer version of the DLL should always work with older executables.  So,
in general, it is always best to keep one version of the DLL on your
system and it should always be the latest version which matches your
installed distribution.
</para></answer></qandaentry>

<qandaentry id="faq.using.missing-packages">
<question><para>Why isn't package XYZ available in Cygwin?</para></question>
<answer>

<para>Probably because there is nobody willing or able to maintain it.  It
takes time, and the priority for the Cygwin Team is the Cygwin package.
The rest is a volunteer effort.  Want to contribute?  See
<ulink url="https://cygwin.com/setup.html"/>.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.old-packages">
<question><para>Why is the Cygwin package of XYZ so out of date?</para></question>
<answer>

<para>(Also: Why is the version of package XYZ older than the version that I
can download from the XYZ web site?  Why is the version of package XYZ
older than the version that I installed on my linux system?  Is there
something special about Cygwin which requires that only an older version
of package XYZ will work on it?)
</para>
<para>Every package in the Cygwin distribution has a maintainer who is
responsible for sending out updates of the package.  This person is a
volunteer who is rarely the same person as the official developer of the
package.  If you notice that a version of a package seems to be out of
date, the reason is usually pretty simple -- the person who is
maintaining the package hasn't gotten around to updating it yet. Rarely,
the newer package actually requires complex changes that the maintainer
is working out. 
</para>
<para>If you urgently need an update, sending a polite message to the cygwin
mailing list pinging the maintainer is perfectly acceptable.  There are
no guarantees that the maintainer will have time to update the package
or that you'll receive a response to your request, however.
</para>
<para>Remember that the operative term here is "volunteer".
</para>
</answer></qandaentry>

<qandaentry id="faq.using.accessing-drives">
<question><para>How can I access other drives?</para></question>
<answer>

<para>You have some flexibility here.
</para>
<para>Cygwin has a builtin "cygdrive prefix" for drives that are not mounted.
You can access any drive, say Z:, as '/cygdrive/z/'.
</para>
<para>In some applications (notably bash), you can use the familiar windows
&lt;drive&gt;:/path/, using posix forward-slashes ('/') instead of Windows
backward-slashes ('\').  (But see the warning below!)  This maps in the
obvious way to the Windows path, but will be converted internally to use
the Cygwin path, following mounts (default or explicit).  For example:
<screen>
	bash$ cd C:/Windows
	bash$ pwd
        /cygdrive/c/Windows
</screen>
and
<screen>
	bash$ cd C:/cygwin
	bash$ pwd
        /
</screen>
for a default setup.  You could also use backward-slashes in the
Windows path, but these would have to be escaped from the shell.
</para>
<para><emphasis role='bold'>Warning:</emphasis> There is some ambiguity in going from a Windows path
to the posix path, because different posix paths, through different
mount points, could map to the same Windows directory.  This matters
because different mount points may be binmode or textmode, so the
behavior of Cygwin apps will vary depending on the posix path used to
get there.
</para>
<para>You can avoid the ambiguity of Windows paths, and avoid typing
"/cygdrive", by explicitly mounting drives to posix paths.  For example:
<screen>
	bash$ mkdir /c
	bash$ mount c:/ /c
	bash$ ls /c
</screen>
Then <literal>/cygdrive/c/Windows</literal> becomes <literal>/c/Windows</literal> which is a
little less typing.
</para>
<para>Note that you have to enter the mount point into the
<filename>/etc/fstab</filename> file to keep it indefinitely. 
The mount command will only add the mount point for the lifetime
of your current Cygwin session.
</para>
<para>You can change the default <literal>cygdrive</literal> prefix and whether it is binmode or textmode using the <filename>/etc/fstab</filename> file
as well.  See the Cygwin User's Guide at
<ulink url="https://cygwin.com/cygwin-ug-net/using.html#mount-table"/>
for more details.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.copy-and-paste">
<question><para>How can I copy and paste into Cygwin console windows?</para></question>
<answer>

<para>First, consider using mintty instead of the standard console
window.  In mintty, selecting with the left-mouse also copies,
and middle-mouse pastes.  It couldn't be easier!
</para>
<para>In Windows's console window, open the properties dialog.
The options contain a toggle button, named "Quick edit mode".  It must
be ON.  Save the properties.
</para>
<para>You can also bind the insert key to paste from the clipboard by adding 
the following line to your .inputrc file: 
<screen>
	"\e[2~": paste-from-clipboard 
</screen>
</para>
</answer></qandaentry>

<qandaentry id="faq.using.firewall">
<question><para>What firewall should I use with Cygwin? </para></question>
<answer>

<para>We have had good reports about Kerio Personal Firewall, ZoneLabs
Integrity Desktop, and the Windows built-in firewall. Other well-known
products including ZoneAlarm and Norton Internet Security have caused
problems for some users but work fine for others. At last report,
Agnitum Outpost did not work with Cygwin.  If you are having strange
connection-related problems, disabling the firewall is a good
troubleshooting step (as is closing or disabling all other running
applications, especially resource-intensive processes such as indexed
search).
</para>
<para>On the whole, Cygwin doesn't care which firewall is used.  The few rare
exceptions have to do with socket code.
Cygwin uses sockets to implement many of its functions, such as IPC.
Some overzealous firewalls install themselves deeply into the winsock
stack (with the 'layered service provider' API) and install hooks
throughout.  Sadly the mailing list archives are littered with examples
of poorly written firewall-type software that causes things to break.
Note that with many of these products, simply disabling the firewall
does not remove these changes; it must be completely uninstalled.
</para>
<para>See also <ulink url="https://cygwin.com/faq/faq.html#faq.using.bloda"/>
for a list of applications that have been known, at one time or another, to 
interfere with the normal functioning of Cygwin.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.sharing-files">
<question><para>How can I share files between Unix and Windows?</para></question>
<answer>

<para>During development, we have Linux boxes running Samba and NFS as well
as Windows machines.  We often build with cross-compilers under Linux and copy
binaries and source to the Windows system or just toy with them
directly off the Samba-mounted partition.  Or, we use the Microsoft NFS
client and just use NFS shares on Linux from Windows.  And then there are
tools like <literal>scp</literal>, <literal>ftp</literal>,
<literal>rsync</literal>, ...
</para>
</answer></qandaentry>

<qandaentry id="faq.using.case-sensitive">
<question><para>Is Cygwin case-sensitive??</para></question>
<answer>

<para>Several Unix programs expect to be able to use to filenames
spelled the same way, but with different case.  A prime example
of this is perl's configuration script, which wants
<literal>Makefile</literal> and <literal>makefile</literal>.  Windows can't
tell the difference between files with just different case, so the
configuration fails.
</para>
<para>To help with this problem, Cygwin supports case sensitivity.  For a
detailed description how to use that feature see the Cygwin User's Guide at
<ulink url="https://cygwin.com/cygwin-ug-net/using-specialnames.html"/>.
</para>

</answer></qandaentry>

<qandaentry id="faq.using.dos-filenames">
<question><para>What about DOS special filenames?</para></question>
<answer>

<para>In Windows, files cannot be named com1, lpt1, or aux (to name a few);
either as the root filename or as the extension part.  If you do, you'll have
trouble.  Unix programs don't avoid these names which can make things
interesting.  E.g., the perl distribution has a file called
<literal>aux.sh</literal>.  The perl configuration tries to make sure that
<literal>aux.sh</literal> is there, but an operation on a file with the magic
letters 'aux' in it will hang.
</para>
<para>At least that's what happens when using native Windows tools.  Cygwin
can deal with these filenames just fine.  Again, see the User's Guide at
<ulink url="https://cygwin.com/cygwin-ug-net/using-specialnames.html"/>
for a detailed description of what's possible with filenames and what is not.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.hangs">
<question><para>When it hangs, how do I get it back?</para></question>
<answer>

<para>If something goes wrong and the tools hang on you for some reason (easy
to do if you try and read a file called aux.sh), first try hitting ^C to
return to bash or the cmd prompt.
</para>
<para>If you start up another shell, and applications don't run, it's a good
bet that the hung process is still running somewhere.  Use the Task
Manager, pview, or a similar utility to kill the process.
</para>
<para>And, if all else fails, there's always the reset button/power switch.
In theory this should never be necessary, though.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.directory-structure">
<question><para>Why the weird directory structure?</para></question>
<answer>

<para>Why do /lib and /usr/lib (and /bin, /usr/bin) point to the same thing?
</para>
<para>Why use mounts instead of symbolic links?
</para>
<para>Can I use a disk root (e.g., C:\) as Cygwin root?  Why is this discouraged?
</para>
<para>After a new installation in the default location, your mount points will
look something like this:
</para>
<screen>
	bash$ mount
	C:\cygwin\bin on /usr/bin type ntfs (binary,auto)
	C:\cygwin\lib on /usr/lib type ntfs (binary,auto)
	C:\cygwin on / type ntfs (binary,auto)
	C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
</screen>

<para>Note that /bin and /usr/bin point to the same location, as do /lib and
/usr/lib.  This is intentional, and you should not undo these mounts
unless you <emphasis>really</emphasis> know what you are doing.
</para>
<para>Various applications and packages may expect to be installed in /lib or
/usr/lib (similarly /bin or /usr/bin).  Rather than distinguish between
them and try to keep track of them (possibly requiring the occasional
duplication or symbolic link), it was decided to maintain only one
actual directory, with equivalent ways to access it.
</para>
<para>Symbolic links had been considered for this purpose, but were dismissed
because they do not always work on Samba drives.  Also, mounts are
faster to process because no disk access is required to resolve them.
</para>
<para>Note that non-cygwin applications will not observe Cygwin mounts (or
symlinks for that matter).  For example, if you use WinZip to unpack the
tar distribution of a Cygwin package, it may not get installed to the
correct Cygwin path.  <emphasis>So don't do this!</emphasis>
</para>
<para>It is strongly recommended not to make the Cygwin root directory the
same as your drive's root directory, unless you know what you are doing
and are prepared to deal with the consequences.  It is generally easier
to maintain the Cygwin hierarchy if it is isolated from, say, C:\.  For
one thing, you avoid possible collisions with other (non-cygwin)
applications that may create (for example) \bin and \lib directories.
(Maybe you have nothing like that installed now, but who knows about
things you might add in the future?)
</para>
</answer></qandaentry>

<qandaentry id="faq.using.anti-virus">
<question><para>How do anti-virus programs like Cygwin?</para></question>
<answer>

<para>Users have reported that NAI (formerly McAfee) VirusScan for NT (and
others?) is incompatible with Cygwin.  This is because it tries to scan
the newly loaded shared memory in cygwin1.dll, which can cause fork() to
fail, wreaking havoc on many of the tools.  (It is not confirmed that
this is still a problem, however.)
</para>
<para>There have been several reports of NAI VirusScan causing the system to
hang when unpacking tar.gz archives.  This is surely a bug in VirusScan,
and should be reported to NAI.  The only workaround is to disable
VirusScan when accessing these files.  This can be an issue during
setup, and is discussed in that FAQ entry.
</para>
<para>Some users report a significant performance hit using Cygwin when their
anti-virus software is enabled.  Rather than disable the anti-virus
software completely, it may be possible to specify directories whose
contents are exempt from scanning.  In a default installation, this
would be <literal>C:\cygwin\bin</literal>.  Obviously, this could be
exploited by a hostile non-Cygwin program, so do this at your own risk.
</para>
<para>See also <ulink url="https://cygwin.com/faq/faq.html#faq.using.bloda"/>
for a list of applications that have been known, at one time or another, to
interfere with the normal functioning of Cygwin.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.emacs">
<question><para>Is there a Cygwin port of GNU Emacs?</para></question>
<answer>

<para>Yes.  Install the emacs package.  This provides everything you
need in order to run GNU emacs in a terminal window.  If you also want
to be able to use the X11
(<ulink url="https://x.cygwin.com/"/>)
GUI, install the emacs-X11 package.  In either case, you run emacs by
typing 'emacs' or '/usr/bin/emacs'.
</para>
</answer></qandaentry>

<qandaentry id="faq.using.xemacs">
<question><para>Is there a Cygwin port of XEmacs?</para></question>
<answer>

<para>Yes.  It can be used in three different modes:</para>
<para><itemizedlist>
<listitem><para>X11 (<ulink url="https://x.cygwin.com/"/>) GUI</para></listitem>
</itemizedlist></para>
<para>You have to <emphasis>set</emphasis> the DISPLAY environment variable
before starting xemacs.</para>
<screen>
	bash$ DISPLAY=127.0.0.1:0 xemacs &amp;
</screen>
<para><itemizedlist>
<listitem><para>Windows native GUI</para></listitem>
</itemizedlist></para>
<para>You have to <emphasis>unset</emphasis> the DISPLAY environment variable
before starting xemacs.</para>
<screen>
	bash$ DISPLAY= xemacs &amp;
</screen>
<para><itemizedlist>
<listitem><para>Console mode</para></listitem>
</itemizedlist></para>
<para>Start xemacs with -nw in a terminal (native or X11) window</para>
<screen>
	bash$ xemacs -nw
</screen>
<para>To use all the standard packages with XEmacs you should download the following
two packages:</para>
<para><itemizedlist>
<listitem><para>xemacs-sumo - XEmacs standard packages</para></listitem>
<listitem><para>xemacs-mule-sumo - XEmacs MULE (MUlti Lingual Emacs) packages</para></listitem>
</itemizedlist></para>
</answer></qandaentry>

<qandaentry id="faq.using.symlinkstoppedworking">
<question><para>Why don't some of my old symlinks work anymore?</para></question>
<answer>

<para>Cygwin supports multiple character sets.  Symlinks created with Cygwin
are using the UTF-16 character set, which is portable across all character
sets.  Old symlinks were written using your current Windows codepage, which
is not portable across all character sets.  If the target of the symlink
doesn't resolve anymore, it's very likely that the symlink points to a target
filename using native, non-ASCII characters, and you're now using another
character set than way back when you created the symlink.</para>

<para>Solution: Delete the symlink and create it again under you new Cygwin.
The new symlink will be correctly point to the target no matter what character
set you're using in future.</para>
</answer></qandaentry>

<qandaentry id="faq.using.symlinks-samba">
<question><para>Why don't symlinks work on Samba-mounted filesystems?</para></question>
<answer>

<para>Symlinks are marked with "system" file attribute.  Samba does not
enable this attribute by default.  To enable it, consult your Samba
documentation and then add these lines to your samba configuration
file:
</para>
<screen>
	map system = yes
	create mask = 0775
</screen>

<para>Note that the 0775 can be anything as long as the 0010 bit is set.
</para>
<para>Alternatively, use Windows shortcuts as symlinks.  See the CYGWIN
environment variable option "winsymlinks" 
<ulink url="https://cygwin.com/cygwin-ug-net/using-cygwinenv.html"/>
</para>
</answer></qandaentry>

<qandaentry id="faq.using.sshd-in-domain">
<question><para>How do I setup sshd in a domain?</para></question>
<answer>

<para>
If you want to be able to logon with domain accounts to a domain member
machine, you should make sure that the "cyg_server" account under which
the sshd service is usually running, is a domain account.  Otherwise you
might end up with weird problems.  For instance, sshd might fail to load
the child process when trying to login with a domain account.  A potential,
confirmed error message is
</para>

<screen>
  *** fatal error - unable to load user32.dll, Win32 error 1114
</screen>.

<para>
Here's how you set up a sshd with a domain service account.
</para>

<para>
First of all, create a new domain account called "cyg_server".  This
account must be an administrative account, so make sure it's in the
"Administrators" group.  Now create a domain policy which is propagated
to all machines which are supposed to run an sshd service.  This domain
policy should give the following user rights to the "cyg_server" account:
</para>

<screen>
  Act as part of the operating system (SeTcbPrivilege)
  Create a token object               (SeCreateTokenPrivilege)
  Replace a process level token       (SeAssignPrimaryTokenPrivilege)
</screen>

<para>
Now to install sshd on the member machine, logon to that machine as
an admin.  Make sure the aforementioend global policy has been propagated
to this machine.  Examine the Local Security Policy settings and, if
necessary, call gpupdate.
</para>

<para>
If everything looks ok, run bash.  Starting with Windows Vista, make
sure you're running bash elevated.
</para>

<para>
Then run ssh-host-config.  Answer all questions so that "cyg_server" is
used to run the service.  When done, check ownership of
<literal>/var/empty</literal> and all <literal>/etc/ssh*</literal>
files.  All of them must be owned by "cyg_server".  If that's ok, you're
usually all set and you can start the sshd service via
</para>

<screen>
  $ cygrunsrv -S sshd
</screen>

<para>or</para>

<screen>
  $ net start sshd
</screen>

</answer></qandaentry>

<qandaentry id="faq.using.ssh-pubkey-stops-working">
<question><para>Why does public key authentication with ssh fail after updating to Cygwin 1.7.34 or later?</para></question>
<answer>

<para>
This is the result of fixing a long-standing security problem in Cygwin's
POSIX ACL handling.  IEEE 1003.1e draft 17 defines that the permissions
of secondary user and group entries in an ACL are reflected in the group
permission mask by or'ing the permissions of the file's primary group with
all permissions of secondary users and groups in the ACL.  The background
is that this way the standard POSIX permission bits reflect the fact that
<emphasis role='bold'>somebody else</emphasis> has additional, otherwise
potentially invisible permissions on the file.  This relatively complex
interface has been defined in order to ensure that applications that are
compliant with IEEE 1003.1 (“POSIX.1”) will still function as expected on
systems with ACLs.</para>

<para>So, what does that mean for your situation?  Typically this means the
private key file, for instance <filename>~/.ssh/id_rsa</filename>, has too
open permissions.  OpenSSH expects the permissions of the private key file
to be 0600.  Let's use the default SSH2 RSA keyfile as example:</para>

<screen>
  $ ls -l .ssh/id_rsa
  -rw-------  1 user group 1766 Aug 26  2013 .ssh/id_rsa
</screen>

<para>However, if other accounts can read the file, the key is potentially
compromised.  Consider the file has additional rw- permissions for a group
<literal>bad_guys</literal>.  Up to Cygwin 1.7.33 that would have looked
like this:</para>

<screen>
  $ ls -l .ssh/id_rsa
  -rw-------+ 1 user group 1766 Aug 26  2013 .ssh/id_rsa
</screen>

<para>Notice the extra <emphasis role='bold'>+</emphasis> character following
the permission string.  This shows that additional ACL entries are in the ACL.
But an application only checking the POSIX permission bits (and ssh is one of
them!), will not notice the fact, because it gets the permissions 0600 for the
file.</para>

<para>Starting with Cygwin 1.7.34, the extra permissions are reflected in
the group permission bits per IEEE 1003.1e draft 17:</para>

<screen>
  $ ls -l .ssh/id_rsa
  -rw-rw----+ 1 user group 1766 Aug 26  2013 .ssh/id_rsa
</screen>

<para>So now ssh will notice that the file has extra permissions and it will
complain.  The same problem occurs if the file
<filename>~/.ssh/authorized_keys</filename> has too open permissions.  On
the client side you won't get any helping text, though, other than that you're
suddenly asked for a password.  That's a rather good hint to have a closer
look at the server's <filename>~/.ssh/authorized_keys</filename> file.</para>

<para>To fix the permissions of your private key file or your
<filename>~/.ssh/authorized_keys</filename> file, simply use the
<command>setfacl</command> command with the <literal>-b</literal> option. 
This removes all additional ACL entries and thus fixes the permissions to
be not too open:</para>

<screen>
  $ ls -l .ssh/id_rsa
  -rw-rw----+ 1 user group 1766 Aug 26  2013 .ssh/id_rsa
  $ setfacl -b .ssh/id_rsa
  $ ls -l .ssh/id_rsa
  -rw-------  1 user group 1766 Aug 26  2013 .ssh/id_rsa
</screen>

<para>If the second <command>ls</command> command still gives you
<computeroutput>-rw-rw----</computeroutput> permissions after running
the above commands, it is proably because the file's primary group
is your user's personal group:</para>

<screen>
  $ ls -l .ssh/id_rsa
  -rw-rw----  1 Fred Fred 1766 Aug 26  2013 .ssh/id_rsa
</screen>

<para>Since the Windows security system treats groups and users as
much the same thing, a change to the user or group permissions on
such a file reflects the change to both user and group. In effect,
mode 0600 becomes mode 0660. Because we are saying we want these
files to be readable only by our user, the fix for this is easy:</para>

<screen>
  $ chgrp `id -g` ~/.ssh/*
</screen>

<para>That resets the group on these files to your default group
which should be something like <computeroutput>Users</computeroutput>,
depending on your local configuration. If that doesn't work, you can
try something like this instead:</para>

<screen>
  $ chgrp None ~/.ssh/*
</screen>

<para>That group always exists, but its name is different on
non-English versions of Windows. You might also want to use a
domain group instead of a local group if your site uses Windows
domains. For example, you might want to use the <computeroutput>Domain
Users</computeroutput> group instead.</para>

<para>For more information on <command>setfacl</command>, see
<ulink url="https://cygwin.com/cygwin-ug-net/setfacl.html"/></para>
</answer></qandaentry>

<qandaentry id="faq.using.same-with-rhosts">
<question><para>Why is my .rhosts file not recognized by rlogin anymore after updating to Cygwin 1.7.34?</para></question>
<answer>

<para>The problem is exactly the same as with the key files of SSH.  See
<xref linkend="faq.using.ssh-pubkey-stops-working"/>.</para>

<para>The solution is the same:</para>

<screen>
  $ ls -l .rhosts
  -rw-rw----+ 1 user group 42 Nov 12  2010 .rhosts
  $ setfacl -b .rhosts
  $ ls -l .rhosts
  -rw-------  1 user group 42 Nov 12  2010 .rhosts
</screen>

</answer></qandaentry>

<qandaentry id="faq.using.same-with-permissions">
<question><para>Why do my files have extra permissions after updating to Cygwin 1.7.34?</para></question>
<answer>

<para>The problem is exactly the same as with the key files of SSH.  See
<xref linkend="faq.using.ssh-pubkey-stops-working"/>.</para>

<para>The solution is the same:</para>

<screen>
  $ ls -l *
  -rw-rwxr--+ 1 user group 42 Nov 12  2010 file1
  -rw-rwxr--+ 1 user group 42 Nov 12  2010 file2
  $ setfacl -b *
  $ ls -l *
  -rw-r--r--  1 user group 42 Nov 12  2010 file1
  -rw-r--r--  1 user group 42 Nov 12  2010 file2
</screen>

<para>You may find that newly-created files also have unexpected
permissions:</para>

<screen>
  $ touch foo
  $ ls -l foo
  -rw-rwxr--+ 1 user group 42 Nov 12  2010 foo
</screen>

<para>This probably means that the directory in which you're creating
the files has unwanted default ACL entries that are inherited by
newly-created files and subdirectories.  The solution is again the
same:</para>

<screen>
  $ setfacl -b .
  $ touch bar
  $ ls -l bar
  -rw-r--r--  1 user group 42 Nov 12  2010 bar
</screen>

</answer></qandaentry>

<qandaentry id="faq.using.tcl-tk">
<question><para>Why do my Tk programs not work anymore?</para></question>
<answer>

<para>Previous versions of Tcl/Tk distributed with Cygwin (e.g. tclsh84.exe,
wish84.exe) were not actually "Cygwin versions" of those tools.
They were built as native libraries, which means they did not understand
Cygwin mounts or symbolic links. This lead to all sorts of problems interacting
with true Cygwin programs.</para>

<para>As of February 2012, this was replaced with a version of Tcl/Tk which
uses Cygwin's POSIX APIs and X11 for GUI functionality.  If you get a message
such as this when trying to start a Tk app:</para>

<screen>
  Application initialization failed: couldn't connect to display ""
</screen>

<para>Then you need to start an X server, or if one is already running, set the
<literal>DISPLAY</literal> variable to the proper value.  The Cygwin distribution
includes an X server; please see the <ulink url="https://x.cygwin.com/docs/ug/cygwin-x-ug.html">Cygwin/X User Guide</ulink>
for installation and startup instructions.
</para></answer></qandaentry>

<qandaentry id="faq.using.bloda" xreflabel="BLODA">
<question><para>What applications have been found to interfere with Cygwin?</para></question>
<answer>

<para>From time to time, people have reported strange failures and problems in
Cygwin and Cygwin packages that seem to have no rational explanation.  Among
the most common symptoms they report are fork failures, memory leaks, and file
access denied problems.  These problems, when they have been traced, often appear
to be caused by interference from other software installed on the same PC.  Security
software, in particular, such as anti-virus, anti-spyware, and firewall applications,
often implements its functions by installing hooks into various parts of the system,
including both the Explorer shell and the underlying kernel.  Sometimes these hooks
are not implemented in an entirely transparent fashion, and cause changes in the
behaviour which affect the operation of other programs, such as Cygwin.
</para>
<para>Among the software that has been found to cause difficulties are:</para>
<para><itemizedlist>
<listitem><para>AR Soft RAM Disk</para></listitem>
<listitem><para>ATI Catalyst (some versions)</para></listitem>
<listitem><para>AVAST (disable FILESYSTEM and BEHAVIOR realtime shields)</para></listitem>
<listitem><para>Avira AntiVir</para></listitem>
<listitem><para>BitDefender</para></listitem>
<listitem><para>Bufferzone from Trustware</para></listitem>
<listitem><para>ByteMobile laptop optimization client</para></listitem>
<listitem><para>COMODO Firewall Pro</para></listitem>
<listitem><para>Citrix Metaframe Presentation Server/XenApp (see <ulink url="http://support.citrix.com/article/CTX107825">Citrix Support page</ulink>)</para></listitem>
<listitem><para>Credant Guardian Shield</para></listitem>
<listitem><para>Earthlink Total-Access</para></listitem>
<listitem><para>Forefront TMG</para></listitem>
<listitem><para>Google Desktop</para></listitem>
<listitem><para>Iolo System Mechanic/AntiVirus/Firewall</para></listitem>
<listitem><para>Kerio, Agnitum or ZoneAlarm Personal Firewall</para></listitem>
<listitem><para>LanDesk</para></listitem>
<listitem><para>Lavasoft Web Companion</para></listitem>
<listitem><para>Lenovo IPS Core Service (ipssvc)</para></listitem>
<listitem><para>Lenovo RapidBoot Shield</para></listitem>
<listitem><para>Logitech webcam software with "Logitech process monitor" service</para></listitem>
<listitem><para>MacType</para></listitem>
<listitem><para>NOD32 Antivirus</para></listitem>
<listitem><para>NVIDIA GeForce (some versions)</para></listitem>
<listitem><para>Norton/McAfee/Symantec antivirus or antispyware</para></listitem>
<listitem><para>PC Tools Spyware Doctor</para></listitem>
<listitem><para>Panda Internet Security</para></listitem>
<listitem><para>Sonic Solutions burning software containing DLA component (when DLA disabled)</para></listitem>
<listitem><para>Sophos Anti-Virus 7</para></listitem>
<listitem><para>Spybot S&amp;D TeaTimer</para></listitem>
<listitem><para>Various programs by Wave Systems Corp using wxvault.dll, including Embassy Trust Suite and Embassy Security Center</para></listitem>
<listitem><para>Webroot Spy Sweeper with Antivirus</para></listitem>
<listitem><para>Windows Defender </para></listitem>
<listitem><para>Windows LiveOneCare</para></listitem>
</itemizedlist></para>
<para>Sometimes these problems can be worked around, by temporarily or partially
disabling the offending software.  For instance, it may be possible to disable
on-access scanning in your antivirus, or configure it to ignore files under the
Cygwin installation root.  Often, unfortunately, this is not possible; even disabling
the software may not work, since many applications that hook the operating system
leave their hooks installed when disabled, and simply set them into what is intended
to be a completely transparent pass-through mode.  Sometimes this pass-through is not
as transparent as all that, and the hooks still interfere with Cygwin; in these cases,
it may be necessary to uninstall the software altogether to restore normal operation.
</para>
<para>Some of the symptoms you may experience are:</para>
<para><itemizedlist>
<listitem>
<para>Random fork() failures</para>
<para>Caused by hook DLLs that load themselves into every process in the
system.  POSIX fork() semantics require that the memory map of the child process
must be an exact duplicate of the parent process' layout.  If one of these DLLs
loads itself at a different base address in the child's memory space as compared
to the address it was loaded at in the parent, it can end up taking the space that
belonged to a different DLL in the parent.  When Cygwin can't load the original
DLL at that same address in the child, the fork() call has to fail.
</para>
</listitem>
<listitem>
<para>File access problems</para>
<para>Some programs (e.g., virus scanners with on-access scanning) scan or
otherwise operate on every file accessed by all the other software running on
your computer.  In some cases they may retain an open handle on the file even
after the software that is really using the file has closed it.  This has been
known to cause operations such as deletes, renames and moves to fail with
access denied errors.  In extreme cases it has been known for scanners to leak
file handles, leading to kernel memory starvation.
</para>
</listitem>
<listitem>
<para>Networking issues</para>
<para>Firewall software sometimes gets a bit funny about Cygwin.  It's not
currently understood why; Cygwin only uses the standard Winsock2 API, but
perhaps in some less-commonly used fashion that doesn't get as well tested
by the publishers of firewalls.  Symptoms include mysterious failures to
connect, or corruption of network data being sent or received.</para>
</listitem>
<listitem>
<para>Memory and/or handle leaks</para>
<para>Some applications that hook into the Windows operating system exhibit
bugs when interacting with Cygwin that cause them to leak allocated memory
or other system resources.  Symptoms include complaints about out-of-memory
errors and even virtual memory exhaustion dialog boxes from the O/S; it is
often possible to see the excess memory allocation using a tool such as
Task Manager or Sysinternals' Process Explorer, although interpreting the
statistics they present is not always straightforward owing to complications
such as virtual memory paging and file caching.</para>
</listitem>
</itemizedlist></para>
</answer></qandaentry>

<qandaentry id='faq.using.fixing-fork-failures'>
  <question><para>How do I fix <literal>fork()</literal> failures?</para></question>
  <answer>
  <para>Unfortunately, Windows does not use the fork/exec model of process creation
  found in UNIX-like OSes, so it is difficult for Cygwin to implement a reliable and
  correct <literal>fork()</literal>, which can lead to error messages such as:</para>
  <para><itemizedlist>
    <listitem>unable to remap <emphasis>somedll</emphasis> to same address as parent</listitem>
    <listitem>couldn't allocate heap</listitem>
    <listitem>died waiting for dll loading</listitem>
    <listitem>child -1 - died waiting for longjmp before initialization</listitem>
    <listitem>STATUS_ACCESS_VIOLATION</listitem>
    <listitem>resource temporarily unavailable</listitem>
  </itemizedlist></para>
  <para>Potential solutions for the above errors:</para>
  <para><itemizedlist>
    <listitem>Restart whatever process is trying (and failing) to use
    <literal>fork()</literal>. Sometimes Windows sets up a process
    environment that is even more hostile to <literal>fork()</literal> than usual.</listitem>
    <listitem>Ensure that you have eliminated (not just disabled) all
    software on the <xref linkend="faq.using.bloda"/>.
    </listitem>
    <listitem>Switch from 32-bit Cygwin to 64-bit Cygwin, if your OS and CPU support that.
    With the bigger address space <literal>fork()</literal> is less likely to fail.</listitem>
    <listitem>
      <para>
      Try setting the environment variable CYGWIN to "detect_bloda", which
      enables some extra debugging, which may indicate what other software is
      causing the problem.
      </para>
      <para>
      See <ulink url="https://cygwin.com/ml/cygwin/2012-02/msg00797.html">this
      mail</ulink> for more information.
      </para>
    </listitem>
    <listitem>
      <para>
	Force a full rebase: Run <command>rebase-trigger fullrebase</command>,
	exit all Cygwin programs and run Cygwin setup.
      </para>
      <para>
	By default, Cygwin's setup program automatically performs an incremental
	rebase of newly installed files.  Forcing a full rebase causes the
	rebase map to be cleared before doing the rebase.
      </para>
      <para>
	See <literal>/usr/share/doc/rebase/README</literal> and
	<literal>/usr/share/doc/Cygwin/_autorebase.README</literal> for more
	details.
      </para>
      <para>Please note that installing new packages or updating existing
      ones undoes the effects of rebase and often causes fork() failures to
      reappear.
      </para>
    </listitem>
    </itemizedlist></para>
  <para>See the <ulink url="https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process">
  process creation</ulink> section of the User's Guide for the technical reasons it is so
  difficult to make <literal>fork()</literal> work reliably.</para>
</answer>
</qandaentry>
</qandadiv>