PlaneteCasio
/
libc
1
0
Fork 0
Code Issues 6 Pull Requests Releases Wiki Activity

Remove references to older Cygwin releases from documentation 

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This commit is contained in:
Corinna Vinschen 2016-03-18 22:52:04 +01:00
parent 97d1536d17
commit 83029bb69e
15 changed files with 107 additions and 166 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
winsup/doc/cygserver.xml
View File

@ -27,11 +27,6 @@
passwords in <command>set(e)uid</command> does not require running
Cygserver. For details, see <xref linkend="ntsec-setuid-overview"></xref>.
</para></listitem>
<listitem><para>This functionality is no longer used since Cygwin 1.7.6,
but the interface is still available: Control slave tty/pty handle dispersal
from tty owner to other processes without compromising the owner processes'
security. Starting with Cygwin 1.7.6 another safe mechanism to share tty/pty
handles is used.</para></listitem>
</itemizedlist>
</sect2>

8
winsup/doc/cygwinenv.xml
View File

@ -119,8 +119,8 @@ system call will immediately fail.</para>
<title>Obsolete options</title>
<para>
Certain CYGWIN options available in past releases have been removed in
Cygwin 1.7 for one reason or another. These obsolete options are listed
Certain CYGWIN options available in past releases have been removed over
time for one reason or another. These obsolete options are listed
below.</para>
<itemizedlist mark="bullet">
@ -225,8 +225,8 @@ Windows programs.</para>
<listitem>
<para><envar>(no)upcaseenv</envar> - This option could be used to convert
all environment variables to uppercase. This was the default behavior in
releases prior to Cygwin 1.7. Since keeping the case of environment
variables intact is POSIXly correct, Cygwin now does not change the case
older releases of Cygwin. Since keeping the case of environment variables
intact is POSIXly correct, Cygwin now does not change the case
of environment variables, except for a restricted set to maintain minimal
backward compatibility. The current list of always uppercased variables is:
</para>

5
winsup/doc/faq-api.xml
View File

@ -278,8 +278,9 @@ shared library. First of all, since October 1998 every Cygwin DLL has
been named <literal>cygwin1.dll</literal> and has a 1 in the release name.
Additionally, there are DLL major and minor numbers that correspond to
the name of the release, and a release number. In other words,
cygwin-1.7.1-2 is <literal>cygwin1.dll</literal>, major version 7, minor
version 1, release 2.
cygwin-2.4.1-1 is <literal>cygwin1.dll</literal>, major version 2, minor
version 4, release 1. -1 is a subrelease number required by the distro
versioning scheme. It's not actually part of the Cygwin DLL version number.
</para>
<para>The <literal>cygwin1.dll</literal> major version number gets incremented
only when a change is made that makes existing software incompatible. For

9
winsup/doc/faq-setup.xml
View File

@ -709,9 +709,9 @@ easy way to do it. Full instructions for constructing a portable Cygwin
on CD by hand can be found on the mailing list at
<ulink url="https://www.cygwin.com/ml/cygwin/2003-07/msg01117.html"/>
(Thanks to fergus at bonhard dot uklinux dot net for these instructions.)
Please note that these instructions are rather old and are referring to the
Please note that these instructions are very old and are referring to the
somewhat different setup of a Cygwin 1.5.x release. As soon as somebody set
this up for Cygwin 1.7, we might add this information here.
this up for recent Cygwin releases, we might add this information here.
</para>
</answer></qandaentry>
@ -719,9 +719,8 @@ this up for Cygwin 1.7, we might add this information here.
<question><para>How do I save, restore, delete, or modify the Cygwin information stored in the registry?</para></question>
<answer>
<para>Since Cygwin 1.7, there's nothing important in the registry anymore,
except for the installation directory information stored there for the sake
of setup-x86{_64}.exe. There's nothing left to manipulate anymore.
<para>Cygwin doesn't store anything important in the registry anymore for
quite some time. There's no reason to save, restore or delete it.
</para></answer></qandaentry>
</qandadiv>

25
winsup/doc/faq-using.xml
View File

@ -772,9 +772,8 @@ of this is perl's configuration script, which wants
tell the difference between files with just different case, so the
configuration fails.
</para>
<para>To help with this problem, Cygwin supports case sensitivity
starting with Cygwin 1.7.0. For a detailed description how to use that
feature see the Cygwin User's Guilde at
<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>
@ -793,8 +792,7 @@ interesting. E.g., the perl distribution has a file called
letters 'aux' in it will hang.
</para>
<para>At least that's what happens when using native Windows tools. Cygwin
1.7.0 and later can deal with these filenames just fine. Again, see the
User's Guide at
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>
@ -950,14 +948,13 @@ two packages:</para>
<question><para>Why don't some of my old symlinks work anymore?</para></question>
<answer>
<para>Beginning with Cygwin 1.7, Cygwin supports multiple character sets.
Symlinks created with Cygwin 1.7 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>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
@ -1054,7 +1051,7 @@ usually all set and you can start the sshd service via
</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?</para></question>
<question><para>Why does public key authentication with ssh fail after updating to Cygwin 1.7.34 or later?</para></question>
<answer>
<para>

50
winsup/doc/highlights.xml
View File

@ -74,10 +74,10 @@ a POSIX-compliant one. The implementation details are safely hidden in the
Cygwin DLL. UNC pathnames (starting with two slashes) are supported for
network paths.</para>
<para>Since version 1.7.0, the layout of this POSIX view of the Windows file
system space is stored in the <filename>/etc/fstab</filename> file. Actually,
there is a system-wide <filename>/etc/fstab</filename> file as well as a
user-specific fstab file <filename>/etc/fstab.d/${USER}</filename>.</para>
<para>The layout of this POSIX view of the Windows file system space is
stored in the <filename>/etc/fstab</filename> file. Actually, there is a
system-wide <filename>/etc/fstab</filename> file as well as a user-specific
fstab file <filename>/etc/fstab.d/${USER}</filename>.</para>
<para>At startup the DLL has to find out where it can find the
<filename>/etc/fstab</filename> file. The mechanism used for this is simple.
@ -130,23 +130,22 @@ guaranteed to be unique. However, we have not found this to be a significant
problem because of the low probability of generating a duplicate inode number.
</para>
<para>Cygwin 1.7 and later supports Extended Attributes (EAs) via the
linux-specific function calls <function>getxattr</function>,
<function>setxattr</function>, <function>listxattr</function>, and
<function>removexattr</function>. All EAs on Samba or NTFS are treated as
user EAs, so, if the name of an EA is "foo" from the Windows perspective,
it's transformed into "user.foo" within Cygwin. This allows Linux-compatible
EA operations and keeps tools like <command>attr</command>, or
<command>setfattr</command> happy.
<para>Cygwin supports Extended Attributes (EAs) via the linux-specific function
calls <function>getxattr</function>, <function>setxattr</function>,
<function>listxattr</function>, and <function>removexattr</function>. All EAs
on Samba or NTFS are treated as user EAs, so, if the name of an EA is "foo"
from the Windows perspective, it's transformed into "user.foo" within Cygwin.
This allows Linux-compatible EA operations and keeps tools like
<command>attr</command>, or <command>setfattr</command> happy.
</para>
<para><function>chroot</function> is supported since Cygwin 1.1.3.
However, chroot is not a concept known by Windows. This implies some serious
restrictions. First of all, the <function>chroot</function> call isn't a
privileged call. Any user may call it. Second, the chroot environment
isn't safe against native windows processes. Given that, chroot in Cygwin
is only a hack which pretends security where there is none. For that reason
the usage of chroot is discouraged.
<para><function>chroot</function> is supported. Kind of. Chroot is not a
concept known by Windows. This implies some serious restrictions. First of
all, the <function>chroot</function> call isn't a privileged call. Any user
may call it. Second, the chroot environment isn't safe against native windows
processes. Given that, chroot in Cygwin is only a hack which pretends security
where there is none. For that reason the usage of chroot is discouraged.
Don't use it unless you really, really know what you're doing.
</para>
</sect2>
@ -347,14 +346,11 @@ completely transparent to the application. Cygwin's implementation also
supports the getpeereid BSD extension. However, Cygwin does not yet support
descriptor passing.</para>
<para>IPv6 is supported beginning with Cygwin release 1.7.0. This
support is dependent, however, on the availability of the Windows IPv6
stack. The IPv6 stack was "experimental", i.e. not feature complete in
Windows 2003 and earlier. Full IPv6 support became available starting
with Windows Vista and Windows Server 2008. Cygwin does not depend on
the underlying OS for the (newly implemented) <function>getaddrinfo</function>
and <function>getnameinfo</function> functions. Cygwin 1.7.0 adds
replacement functions which implement the full functionality for IPv4.</para>
<para>IPv6 is supported. This support is dependent, however, on the
availability of the Windows IPv6 stack. The IPv6 stack was "experimental",
i.e. not feature complete in Windows 2003 and earlier. Full IPv6 support
became only available starting with Windows Vista and Windows Server 2008.
</para>
</sect2>

26
winsup/doc/new-features.xml
View File

@ -9,25 +9,25 @@
<itemizedlist mark="bullet">
<listitem><para>
- Full set of POSIX.1e ACL API functions now implemented.
New APIs: acl_add_perm, acl_calc_mask, acl_clear_perms, acl_copy_entry,
acl_copy_ext, acl_copy_int, acl_create_entry, acl_delete_def_file,
acl_delete_entry, acl_delete_perm, acl_dup, acl_free, acl_from_text,
acl_get_entry, acl_get_fd, acl_get_file, acl_get_permset, acl_get_qualifier,
acl_get_tag_type, acl_init, acl_set_fd, acl_set_file, acl_set_permset,
acl_set_qualifier, acl_set_tag_type, acl_size, acl_to_text, acl_valid.
Full set of POSIX.1e ACL API functions now implemented.
New APIs: acl_add_perm, acl_calc_mask, acl_clear_perms, acl_copy_entry,
acl_copy_ext, acl_copy_int, acl_create_entry, acl_delete_def_file,
acl_delete_entry, acl_delete_perm, acl_dup, acl_free, acl_from_text,
acl_get_entry, acl_get_fd, acl_get_file, acl_get_permset, acl_get_qualifier,
acl_get_tag_type, acl_init, acl_set_fd, acl_set_file, acl_set_permset,
acl_set_qualifier, acl_set_tag_type, acl_size, acl_to_text, acl_valid.
</para></listitem>
<listitem><para>
- Most libacl extensions now implemented, too:
New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
acl_from_mode, acl_get_perm, acl_to_any_text.
Most libacl extensions now implemented, too:
New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
acl_from_mode, acl_get_perm, acl_to_any_text.
</para></listitem>
<listitem><para>
- Including &lt;sys/acl.h&gt; now *only* includes the POSIX ACL API. To include
the old Solaris API, include &lt;cygwin/acl.h&gt;.
Including &lt;sys/acl.h&gt; now *only* includes the POSIX ACL API. To include
the old Solaris API, include &lt;cygwin/acl.h&gt;.
</para></listitem>
<listitem><para>

4
winsup/doc/overview.xml
View File

@ -113,7 +113,7 @@ have seen continuous development.
</para>
<para>
The biggest major improvement in this development is the 1.7 release in
The biggest major improvement in this development was the 1.7 release in
2009, which dropped Windows 95/98/Me support in favor of using Windows
NT features more extensively. It adds a lot of new features like
case-sensitive filenames, NFS interoperability, IPv6 support and much
@ -121,7 +121,7 @@ more.</para>
<para>The latest big improvement is the 64 bit Cygwin DLL which
allows to run natively on AMD64 Windows machines. The first release
available in a 64 bit version is 1.7.19.</para>
available in a 64 bit version was 1.7.19.</para>
</sect1>

15
winsup/doc/pathnames.xml
View File

@ -391,14 +391,13 @@ followed by the path to which the link points. They are marked with the
DOS SYSTEM attribute so that only files with that attribute have to be
read to determine whether or not the file is a symbolic link.</para>
<note><para>Starting with Cygwin 1.7, symbolic links are using UTF-16 to encode
the filename of the target file, to better support internationalization.
Symlinks created by older Cygwin releases can be read just fine. However,
you could run into problems with them if you're now using another character
set than the one you used when creating these symlinks
(see <xref linkend="setup-locale-problems"></xref>). Please note that this
new UTF-16 style of symlinks is not compatible with older Cygwin release,
which can't read the target filename correctly.</para></note>
<note><para>Cygwin symbolic links are using UTF-16 to encode the filename of
the target file, to better support internationalization. Symlinks created by
old Cygwin releases can be read just fine. However, you could run into
problems with them if you're now using another character set than the one you
used when creating these symlinks
(see <xref linkend="setup-locale-problems"></xref>).
</para></note>
</listitem>
<listitem>

5
winsup/doc/setup-env.xml
View File

@ -30,9 +30,8 @@ This is, of course, just an example. For the recognized settings of the
<para>
Locale support is controlled by the <envar>LANG</envar> and
<envar>LC_xxx</envar> environment variables. Since Cygwin 1.7.2, all of
them are honored and have a meaning. For a more detailed description see
<xref linkend="setup-locale"></xref>.
<envar>LC_xxx</envar> environment variables. For a more detailed description
see <xref linkend="setup-locale"></xref>.
</para>
<para>

42
winsup/doc/setup-locale.xml
View File

@ -60,11 +60,10 @@ provided by the gettext package under Cygwin.</para>
<para>
At application startup, the application's locale is set to the default
"C" or "POSIX" locale. Under Cygwin 1.7.2 and later, this locale defaults
to the ASCII character set on the application level. If you want to stick
to the "C" locale and only change to another charset, you can define this
by setting one of the locale environment variables to "C.charset". For
instance</para>
"C" or "POSIX" locale. This locale defaults to the ASCII character set
on the application level. If you want to stick to the "C" locale and only
change to another charset, you can define this by setting one of the locale
environment variables to "C.charset". For instance</para>
<screen>
"C.ISO-8859-1"
@ -117,10 +116,9 @@ interoperability with applications running in the default "C.UTF-8" locale.
</para>
<para>
Starting with Cygwin 1.7.2, the language and territory are used to
fetch locale-dependent information from Windows. If the language and
territory are not known to Windows, the <function>setlocale</function>
function fails.</para>
The language and territory are used to fetch locale-dependent information
from Windows. If the language and territory are not known to Windows, the
<function>setlocale</function> function fails.</para>
<para>The following modifiers are recognized. Any other modifier is simply
ignored for now.</para>
@ -181,10 +179,10 @@ Assume that you've set one of the aforementioned environment variables to some
valid POSIX locale value, other than "C" and "POSIX". Assume further that
you're living in Japan. You might want to use the language code "ja" and the
territory "JP", thus setting, say, <envar>LANG</envar> to "ja_JP". You didn't
set a character set, so what will Cygwin use now? Starting with Cygwin 1.7.2,
the default character set is determined by the default Windows ANSI codepage
for this language and territory. Cygwin uses a character set which is the
typical Unix-equivalent to the Windows ANSI codepage. For instance:</para>
set a character set, so what will Cygwin use now? The default character set
is determined by the default Windows ANSI codepage for this language and
territory. Cygwin uses a character set which is the typical Unix-equivalent
to the Windows ANSI codepage. For instance:</para>
<screen>
"en_US" ISO-8859-1
@ -307,25 +305,9 @@ environment, if it's different from the UTF-8 charset.</para>
consist of valid ASCII characters, and only of uppercase letters, digits, and
the underscore for maximum portability.</para></note>
<para>Symbolic links, too, may pose a problem when switching charsets on
the fly. A symbolic link contains the filename of the target file the
symlink points to. When a symlink had been created with older versions
of Cygwin, the current ANSI or OEM character set had been used to store
the target filename, dependent on the old <envar>CYGWIN</envar>
environment variable setting <envar>codepage</envar> (see <xref
linkend="cygwinenv-removed-options"></xref>. If the target filename
contains non-ASCII characters and you use another character set than
your default ANSI/OEM charset, the target filename of the symlink is now
potentially an invalid character sequence in the new character set.
This behaviour is not different from the behaviour in other Operating
Systems. So, if you suddenly can't access a symlink anymore which
worked all these years before, maybe it's because you switched to
another character set. This doesn't occur with symlinks created with
Cygwin 1.7 or later. </para>
<para>Another problem you might encounter is that older versions of
Windows did not install all charsets by default. If you are running
Windows XP or older, you can open the "Regional and Language Options"
Windows XP or 2003, you can open the "Regional and Language Options"
portion of the Control Panel, select the "Advanced" tab, and select
entries from the "Code page conversion tables" list. The following
entries are useful to cygwin: 932/SJIS, 936/GBK, 949/EUC-KR, 950/Big5,

34
winsup/doc/setup-maxmem.xml
View File

@ -9,12 +9,13 @@ Cygwin's heap is extensible. However, it does start out at a fixed size
and attempts to extend it may run into memory which has been previously
allocated by Windows. In some cases, this problem can be solved by
changing a field in the file header which is utilized by Cygwin since
version 1.7.10 to keep the initial size of the application heap. If the
field contains 0, which is the default, the application heap defaults to
a size of 384 Megabyte. If the field is set to any other value between 4 and
2048, Cygwin tries to reserve as much Megabytes for the application heap.
The field used for this is the "LoaderFlags" field in the NT-specific
PE header structure (<literal>(IMAGE_NT_HEADER)->OptionalHeader.LoaderFlags</literal>).</para>
to keep the initial size of the application heap. If the field contains 0,
which is the default, the application heap defaults to a size of 384 Megabyte
on 32 bit Cygwin, 512 Megabyte on 64 bit Cygwin. If the field is set to any
other value between 4 and 2048, Cygwin tries to reserve as much Megabytes
for the application heap. The field used for this is the "LoaderFlags" field
in the NT-specific PE header structure
(<literal>(IMAGE_NT_HEADER)->OptionalHeader.LoaderFlags</literal>).</para>
<para>
This value can be changed for any executable by using a more recent version
@ -42,25 +43,4 @@ up to 3 GB per process. See the Microsoft article
for more information.
</para>
<note>
<para>
Older Cygwin releases only supported a global registry setting to
change the initial heap size for all Cygwin processes. This setting is
not used anymore. However, if you're running an older Cygwin release
than 1.7.10, you can add the <literal>DWORD</literal> value
<literal>heap_chunk_in_mb</literal> and set it to the desired memory limit
in decimal MB. You have to stop all Cygwin processes for this setting to
have any effect. It is preferred to do this in Cygwin using the
<command>regtool</command> program included in the Cygwin package.
(see <xref linkend="regtool"></xref>) This example sets the memory limit
to 1024 MB for all Cygwin processes (use HKCU instead of HKLM if you
want to set this only for the current user):
<screen>
$ regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1024
$ regtool -v list /HKLM/Software/Cygwin
</screen>
</para>
</note>
</sect1>

36
winsup/doc/specialnames.xml
View File

@ -50,10 +50,9 @@ to be readable by the $USER user account itself.</para>
<sect2 id="pathnames-dosdevices"><title>Invalid filenames</title>
<para>Filenames invalid under Win32 are not necessarily invalid
under Cygwin since release 1.7.0. There are a few rules which
apply to Windows filenames. Most notably, DOS device names like
<filename>AUX</filename>, <filename>COM1</filename>,
<para>Filenames invalid under Win32 are not necessarily invalid under Cygwin.
There are a few rules which apply to Windows filenames. Most notably, DOS
device names like <filename>AUX</filename>, <filename>COM1</filename>,
<filename>LPT1</filename> or <filename>PRN</filename> (to name a few)
cannot be used as filename or extension in a native Win32 application.
So filenames like <filename>prn.txt</filename> or <filename>foo.aux</filename>
@ -95,12 +94,12 @@ can create and access files with trailing dots and spaces without problems.
<para>An exception from this rule are some network filesystems (NetApp,
NWFS) which choke on these filenames. They return with an error like
"No such file or directory" when trying to create such files. Starting
with Cygwin 1.7.6, Cygwin recognizes these filesystems and works around
this problem by applying the same rule as for the other forbidden characters.
Leading spaces and trailing dots and spaces will be converted to UNICODE
characters in the private use area. This behaviour can be switched on
explicitely for a filesystem or a directory tree by using the mount option
"No such file or directory" when trying to create such files. Cygwin
recognizes these filesystems and works around this problem by applying
the same rule as for the other forbidden characters. Leading spaces and
trailing dots and spaces will be converted to UNICODE characters in the
private use area. This behaviour can be switched on explicitely for a
filesystem or a directory tree by using the mount option
<literal>dos</literal>.</para>
</sect2>
@ -227,11 +226,8 @@ semaphores, shared memory, and message queues, so a system without a real
</para>
<para>Apart from that, Cygwin automatically simulates POSIX devices
internally. Up to Cygwin 1.7.11, these devices couldn't be seen with the
command <command>ls /dev/</command> although commands such as
<command>ls /dev/tty</command> worked fine. Starting with Cygwin 1.7.12,
the <filename>/dev</filename> directory is automagically populated with
existing POSIX devices by Cygwin in a way comparable with a
internally. The <filename>/dev</filename> directory is automagically
populated with existing POSIX devices by Cygwin in a way comparable with a
<ulink url="http://en.wikipedia.org/wiki/Udev">udev</ulink> based virtual
<filename>/dev</filename> directory under Linux.</para>
@ -245,15 +241,13 @@ Cygwin supports the following character devices commonly found on POSIX systems:
/dev/full
/dev/console Pseudo device name for the current console window of a session.
Up to Cygwin 1.7.9, this was the only name for a console.
Different consoles were indistinguishable.
Cygwin's /dev/console is not quite comparable with the console
device on UNIX machines.
/dev/cons0 Starting with Cygwin 1.7.10, Console sessions are numbered from
/dev/cons1 /dev/cons0 upwards. Console device names are pseudo device
... names, only accessible from processes within this very console
session. This is due to a restriction in Windows.
/dev/cons0 Console sessions are numbered from /dev/cons0 upwards.
/dev/cons1 Console device names are pseudo device names, only accessible
... from processes within this very console session. This is due
to a restriction in Windows.
/dev/tty The current controlling tty of a session.

2
winsup/doc/textbinary.xml
View File

@ -146,7 +146,7 @@ in your project, like this:</para>
$ gcc my_tiny_app.c /lib/binmode.o -o my_tiny_app
</screen>
<para>Starting with Cygwin 1.7.7, you can use the even simpler:</para>
<para>Even simpler:</para>
<screen>
$ gcc my_tiny_app.c -lbinmode -o my_tiny_app

7
winsup/doc/utils.xml
View File

@ -1481,10 +1481,9 @@ D: on /d type fat (binary,user,noumount)
<refsect2 id="utils-limitations">
<title>Limitations</title>
<para>Limitations: there is a hard-coded limit of 64 mount points (up to
Cygwin 1.7.9: 30 mount points). Also, although you can mount to
pathnames that do not start with "/", there is no way to make use of
such mount points.</para>
<para>Limitations: there is a hard-coded limit of 64 mount points.
Also, although you can mount to pathnames that do not start with "/",
there is no way to make use of such mount points.</para>
<para>Normally the POSIX mount point in Cygwin is an existing empty
directory, as in standard UNIX. If this is the case, or if there is a