Mapping path names
Introduction
Cygwin supports both Win32- and POSIX-style paths, where
directory delimiters may be either forward or back slashes. UNC
pathnames (starting with two slashes and a network name) are also
supported.
POSIX operating systems (such as Linux) do not have the concept
of drive letters. Instead, all absolute paths begin with a
slash (instead of a drive letter such as "c:") and all file systems
appear as subdirectories (for example, you might buy a new disk and
make it be the /disk2 directory).
Because many programs written to run on UNIX systems assume
the existance of a single unified POSIX file system structure, Cygwin
maintains a special internal POSIX view of the Win32 file system
that allows these programs to successfully run under Windows. Cygwin
uses this mapping to translate from POSIX to Win32 paths as
necessary.
The Cygwin Mount Table
The /etc/fstab file is used to map Win32
drives and network shares into Cygwin's internal POSIX directory tree.
This is a similar concept to the typical UNIX fstab file. The mount
points stored in /etc/fstab are globally set for
all users. Sometimes there's a requirement to have user specific
mount points. The Cygwin DLL supports user specific fstab files.
These are stored in the directory /etc/fstab.d
and the name of the file is the Cygwin username of the user, as it's
stored in the /etc/passwd file. The content of the
user specifc file is identical to the system-wide
fstab file.
The file fstab contains descriptive information about the various file
systems. fstab is only read by programs, and not written; it is the
duty of the system administrator to properly create and maintain this
file. Each filesystem is described on a separate line; fields on each
line are separated by tabs or spaces. Lines starting with '#' are
comments.
The first field describes the block special device or
remote filesystem to be mounted. On Cygwin, this is the native Windows
path which the mount point links in. As path separator you MUST use a
slash. Usage of a backslash might lead to unexpected results. UNC
paths (using slashes, not backslashes) are allowed. If the path
contains spaces these can be escaped as '\040'.
The second field describes the mount point for the filesystem.
If the name of the mount point contains spaces these can be
escaped as '\040'.
The third field describes the type of the filesystem.
Cygwin supports any string here, since the file system type is usually
not evaluated. The noticable exception is the file system type
cygdrive. This type is used to set the cygdrive prefix.
The fourth field describes the mount options associated
with the filesystem. It is formatted as a comma separated list of
options. It contains at least the type of mount (binary or text) plus
any additional options appropriate to the filesystem type. Recognized
options are binary, text, nouser, user, exec, notexec, cygexec, nosuid,
posix=[0|1]. The meaning of the options is as follows.
acl - Cygwin uses the filesystem's access control lists (ACLs) to
implement real POSIX permissions (default). This flag only
affects filesystems supporting ACLs (NTFS) and is ignored
otherwise.
noacl - Cygwin ignores filesystem ACLs and only fakes a subset of
permission bits based on the DOS readonly attribute. This
behaviour is the default on FAT and FAT32. The flag is
ignored on NFS filesystems.
binary - Files default to binary mode (default).
text - Files default to CRLF text mode line endings.
nouser - Mount is a system-wide mount.
user - Mount is a user mount.
exec - Treat all files below mount point as executable.
notexec - Treat all files below mount point as not executable.
cygexec - Treat all files below mount point as cygwin executables.
nosuid - No suid files are allowed (currently unimplemented).
posix=0 - Switch off case sensitivity for paths under this mount point.
posix=1 - Switch on case sensitivity for paths under this mount point
(default).
Normally, files ending in certain extensions (.exe, .com, .bat, .btm,
.cmd) are assumed to be executable. Files whose first two characters begin
with '#!' are also considered to be executable.
The exec option is used to instruct Cygwin that the
mounted file is "executable". If the exec option is used
with a directory then all files in the directory are executable.
This option allows other files to be marked as executable and avoids the
overhead of opening each file to check for a '#!'. The
cygexec option is very similar to exec,
but also prevents Cygwin from setting up commands and environment variables
for a normal Windows program, adding another small performance gain. The
opposite of these options is the notexec option, which
means that no files should be marked as executable under that mount point.
Note that nouser mount points are not overridable by a later call
to mount. This is only possible for user mount points.
Mount points given in /etc/fstab are by default nouser
mount points, unless you specify the option user. In contrast, all mount
points in the user specific fstab file are user mount points.
The fifth and sixth field are ignored. They are
so far only specified to keep a Linux-like fstab file layout.
Note that you don't have to specify an fstab entry for the root dir,
unless you want to have the root dir pointing to somewhere entirely
different (hopefully you know what you're doing), or if you want to
mount the root dir with special options (for instance, as text mount).
Example entries:
Just a normal mount point:
c:/foo /bar fat32 binary 0 0
A mount point for a managed, textmode mount:
C:/foo /bar/baz ntfs text,managed 0 0
A mount point for a Windows directory with spaces in it:
C:/Documents\040and\040Settings /docs ext3 binary 0 0
A mount point for a remote directory:
//server/share/subdir /srv/subdir smbfs binary 0 0
This is just a comment:
# This is just a comment
Set the cygdrive prefix to /mnt:
none /mnt cygdrive binary 0 0
Whenever Cygwin generates a Win32 path from a POSIX one, it uses
the longest matching prefix in the mount table. Thus, if
C: is mounted as /c and also
as /, then Cygwin would translate
C:/foo/bar to /c/foo/bar.
This translation is normally only used when trying to derive the
POSIX equivalent current directory. Otherwise, the handling of MS-DOS
filenames bypasses the mount table.
If you want to see the current set of mount points valid in your
session, you can invoking the Cygwin tool mount without
arguments:
Displaying the current set of mount points
bash-3.2$ mount
f:\cygwin\bin on /usr/bin type system (binmode)
f:\cygwin\lib on /usr/lib type system (binmode)
f:\cygwin on / type system (binmode)
e:\src on /usr/src type system (binmode)
c: on /cygdrive/c type user (binmode,noumount)
e: on /cygdrive/e type user (binmode,noumount)
You can also use the mount command to add
new mount points, and the umount to delete
them. However, since they are only noted in memory, these mount
points will disappear as soon as your last Cygwin process ends.
See and for more
information.
Whenever Cygwin cannot use any of the existing mounts to convert
from a particular Win32 path to a POSIX one, Cygwin will
automatically default to an imaginary mount point under the default POSIX
path /cygdrive. For example, if Cygwin accesses
Z:\foo and the Z drive is not currently in the
mount table, then Z:\ would be automatically
converted to /cygdrive/Z. The default
prefix of /cygdrive may be changed in the fstab file
as outlined above.
Additional Path-related Information
The cygpath program provides the ability to
translate between Win32 and POSIX pathnames in shell scripts. See
for the details.
The HOME, PATH, and
LD_LIBRARY_PATH environment variables are automatically
converted from Win32 format to POSIX format (e.g. from
c:\cygwin\bin to /bin, if
there was a mount from that Win32 path to that POSIX path) when a Cygwin
process first starts.
Symbolic links can also be used to map Win32 pathnames to POSIX.
For example, the command
ln -s //pollux/home/joe/data /data would have about
the same effect as creating a mount point from
//pollux/home/joe/data to /data
using mount, except that symbolic links cannot set
the default file access mode. Other differences are that the mapping is
distributed throughout the file system and proceeds by iteratively
walking the directory tree instead of matching the longest prefix in a
kernel table. Note that symbolic links will only work on network
drives that are properly configured to support the "system" file
attribute. Many do not do so by default (the Unix Samba server does
not by default, for example).
Special filenames
DOS devices
Filenames invalid under Win32 are not necessarily invalid
under Cygwin since release 1.7.0. There are a couple of rules which
apply to Windows filenames. First of all, DOS device names like
AUX, COM1,
LPT1 or PRN (to name a few)
cannot be used in a native Win32 application, even with an
extension (prn.txt). Cygwin can handle files with
these names just fine.
Special characters in filenames
Win32 filenames can't contain trailing dots and spaces for backward
compatibility. When trying to create files with trailing dots or spaces,
all of them are removed before the file is created. This restriction does
only affect native Win32 applications. Cygwin applications can create and
access files with trailing dots and spaces without problems.
Some characters are disallowed in filenames on Windows filesystems:
" * : < > ? | \
Cygwin can't fix this, but it has a method to workaround this
restriction. All of the above characters, except for the backslash,
are converted to special UNICODE characters in the range 0xf000 to 0xf0ff
(the "Private use area") when creating or accessing files.
Case sensitive filenames
In the Win32 subsystem filenames are only case-preserved, but not
case-sensitive. You can't access two files in the same directory which
only differ by case, like Abc and
aBc. While NTFS (and some remote filesystems)
support case-sensitivity, the NT kernel starting with Windows XP does
not support it by default. Rather, you have to tweak a registry setting
and reboot. For that reason, case-sensitivity is not supported by Cygwin,
unless you change that registry value.
If you really want case-sensitivity in Cygwin, you can switch it
on by setting the registry value
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
to 0 and reboot the machine. For least surprise, Cygwin expects
this registry value also on Windows NT4 and Windows 2000, which usually
both don't know this registry key. If you want case-sensitivity on these
systems, create that registry value and set it to 0. On these systems
(and *only* on these systems) you don't have to reboot to bring it
into effect.
Note that when installing Microsoft's Services For Unix (SFU), you're asked if
you want to use case-sensitive filenames. If you answer "yes" at this point,
the installer will change the aforementioned registry value to 0, too. So, if
you have SFU installed, there's some chance that the registry value is already
set to case sensitivity.
After you set this registry value to 0, Cygwin will be case-sensitive
by default on NTFS and NFS filesystems. Be aware that using two filenames
which only differ by case might result in some weird interoperability
issues with native Win32 applications. You're using case-sensitivity
at your own risk. You have been warned!
Even if you use case-sensitivity, it might be feasible to switch to
case-insensitivity for certain paths for better interoperability with
native Win32 applications (even if it's just Windows Explorer). You can do
this on a per-mount point base, by using the "posix=0" mount option in
/etc/fstab, or your /etc/fstab.d/$USER file.
For a start, it might be best to switch the cygdrive path to
case-insensitivity, because the default Windows $PATH variable is not
always using the correct case by default. As a result, your shell will
claim that it can't find Windows commands like attrib
or net. Here's an example how you can switch the
cygdrive prefix to case-insensitivity:
Example mount point to enforce case-insensitivity on cygdrive paths
none /cygdrive cygdrive binary,posix=0 0 0
Note that mount points as well as device names and virtual
paths like /proc are always case-sensitive! The only exception are
the subdirs and filenames under /proc/registry, /proc/registry32
and /proc/registry64. Registry access is always case-insensitive.
Read on for more information.
POSIX devices
There is no need to create a POSIX /dev
directory as Cygwin automatically simulates it internally.
These devices cannot be seen with the command ls /dev/
although commands such as ls /dev/tty work fine.
If you want to be able to see all devices in
/dev/, you can use Igor Pechtchanski's
create_devices.sh
script.
Cygwin supports the following character devices commonly found on POSIX systems:
/dev/null
/dev/zero
/dev/full
/dev/console Pseudo device name for the standard console window created
by Windows. Same as the one used for cmd.exe. Every one
of them has this name. It's not quite comparable with the
console device on UNIX machines.
/dev/tty The current tty of a session running in a pseudo tty.
/dev/ptmx Pseudo tty master device.
/dev/ttym
/dev/tty0 Pseudo ttys are numbered from /dev/tty0 upwards as they are
/dev/tty1 requested.
...
/dev/ttyS0 Serial communication devices. ttyS0 == Win32 COM1,
/dev/ttyS1 ttyS1 == COM2, etc.
...
/dev/pipe
/dev/fifo
/dev/mem The physical memory of the machine. Note that access to the
/dev/port physical memory has been restricted with Windows Server 2003.
/dev/kmem Since this OS, you can't access physical memory from user space.
/dev/kmsg Kernel message pipe, for usage with sys logger services.
/dev/random Random number generator.
/dev/urandom
/dev/dsp Default sound device of the system.
Cygwin also has several Windows-specific devices:
/dev/com1 The serial ports, starting with COM1 which is the same as ttyS0.
/dev/com2 Please use /dev/ttySx instead.
...
/dev/conin Same as Windows CONIN$.
/dev/conout Same as Windows CONOUT$.
/dev/clipboard The Windows clipboard, text only
/dev/windows The Windows message queue.
Block devices are accessible by Cygwin processes using fixed POSIX device
names. These POSIX device names are generated using a direct conversion
from the POSIX namespace to the internal NT namespace.
E.g. the first harddisk is the NT internal device \device\harddisk0\partition0
or the first partition on the third harddisk is \device\harddisk2\partition1.
The first floppy in the system is \device\floppy0, the first CD-ROM is
\device\cdrom0 and the first tape drive is \device\tape0. The mapping
to the POSIX /dev namespace is as follows:
/dev/st0 \device\tape0, rewind
/dev/nst0 \device\tape0, no-rewind
/dev/st1 \device\tape1
/dev/nst1 \device\tape1
...
/dev/st15
/dev/nst15
/dev/fd0 \device\floppy0
/dev/fd1 \device\floppy1
...
/dev/fd15
/dev/sr0 \device\cdrom0
/dev/sr1 \device\cdrom1
...
/dev/sr15
/dev/scd0 \device\cdrom0
/dev/scd1 \device\cdrom1
...
/dev/scd15
/dev/sda \device\harddisk0\partition0 (whole disk)
/dev/sda1 \device\harddisk0\partition1 (first partition)
...
/dev/sda15 \device\harddisk0\partition15 (fifteenth partition)
/dev/sdb \device\harddisk1\partition0
/dev/sdb1 \device\harddisk1\partition1
[up to]
/dev/sddx \device\harddisk127\partition0
/dev/sddx1 \device\harddisk127\partition1
...
/dev/sddx15 \device\harddisk127\partition15
if you don't like these device names, feel free to create symbolic
links as they are created on Linux systems for convenience:
ln -s /dev/sr0 /dev/cdrom
ln -s /dev/nst0 /dev/tape
...
The .exe extension
Win32 executable filenames end with .exe
but the .exe need not be included in the command,
so that traditional UNIX names can be used. However, for programs that
end in .bat and .com, you
cannot omit the extension.
As a side effect, the ls filename gives
information about filename.exe if
filename.exe exists and filename
does not. In the same situation the function call
stat("filename",..) gives information about
filename.exe. The two files can be distinguished
by examining their inodes, as demonstrated below.
C:\> ls *
a a.exe b.exe
C:\> ls -i a a.exe
445885548 a 435996602 a.exe
C:\> ls -i b b.exe
432961010 b 432961010 b.exe
If a shell script myprog and a program
myprog.exe coexist in a directory, the shell
script has precedence and is selected for execution of
myprog. Note that this was quite the reverse up to
Cygwin 1.5.19. It has been changed for consistency with the rest of Cygwin.
The gcc compiler produces an executable named
filename.exe when asked to produce
filename. This allows many makefiles written
for UNIX systems to work well under Cygwin.
The /proc filesystem
Cygwin, like Linux and other similar operating systems, supports the
/proc virtual filesystem. The files in this
directory are representations of various aspects of your system,
for example the command cat /proc/cpuinfo
displays information such as what model and speed processor you have.
One unique aspect of the Cygwin /proc filesystem
is /proc/registry, which displays the Windows
registry with each KEY as a directory and each
VALUE as a file. As anytime you deal with the
Windows registry, use caution since changes may result in an unstable
or broken system. There are additionally subdirectories called
/proc/registry32 and /proc/registry64.
They are identical to /proc/registry on 32 bit
host OSes. On 64 bit host OSes, /proc/registry32
opens the 32 bit processes view on the registry, while
/proc/registry64 opens the 64 bit processes view.
The Cygwin /proc is not as complete as the
one in Linux, but it provides significant capabilities. The
procps package contains several utilities
that use it.
The @pathnames
To circumvent the limitations on shell line length in the native
Windows command shells, Cygwin programs expand their arguments
starting with "@" in a special way. If a file
pathname exists, the argument
@pathname expands recursively to the content of
pathname. Double quotes can be used inside the
file to delimit strings containing blank space.
Embedded double quotes must be repeated.
In the following example compare the behaviors of the bash built-in
echo and of the program /bin/echo.
Using @pathname
bash$ echo 'This is "a long" line' > mylist
bash$ echo @mylist
@mylist
c:\> c:\cygwin\bin\echo @mylist
This is a long line