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 /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: bash$ 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. 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). Certain files in Cygwin's /etc directory are read by Cygwin before the mount table has been established. The list of files is /etc/fstab /etc/fstab.d/$USER /etc/passwd /etc/group These file are read using native Windows NT functions which have no notion of Cygwin symlinks or POSIX paths. For that reason there are a few requirements as far as /etc is concerned. To access these files, the Cygwin DLL evaluates it's own full Windows path, strips off the innermost directory component and adds "\etc". Let's assume the Cygwin DLL is installed as C:\cygwin\bin\cygwin1.dll. First the DLL name as well as the innermost directory (bin) is stripped off: C:\cygwin\. Then "etc" and the filename to look for is attached: C:\cygwin\etc\fstab. So the /etc directory must be parallel to the directory in which the cygwn1.dll exists and /etc must not be a Cygwin symlink pointing to another directory. Consequentially none of the files from the above list, including the directory /etc/fstab.dis allowed to be a Cygwin symlink either. However, native NTFS symlinks and reparse points are transparent when accessing the above files so all these files as well as /etc itself may be NTFS symlinks or reparse points. Last but not least, make sure that these files are world-readable. Every process of any user account has to read these files potentially, so world-readability is essential. The only exception are the user specific files /etc/fstab.d/$USER, which only have to be readable by the $USER user account itself. 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. 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. 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: 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. 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 ... 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. bash$ ls * a a.exe b.exe bash$ ls -i a a.exe 445885548 a 435996602 a.exe bash$ 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. 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, see next section. 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 /proc/registry filesystem provides read-only access to the Windows registry. It displays 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. Reserved characters ('/', '\', ':', and '%') or reserved names (. and ..) are converted by percent-encoding: bash$ regtool list -v '\HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices' ... \DosDevices\C: (REG_BINARY) = cf a8 97 e8 00 08 fe f7 ... bash$ cd /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM bash$ ls -l MountedDevices ... -r--r----- 1 Admin SYSTEM 12 Dec 10 11:20 %5CDosDevices%5CC%3A ... bash$ od -t x1 MountedDevices/%5CDosDevices%5CC%3A 0000000 cf a8 97 e8 00 08 fe f7 01 00 00 00 The unnamed (default) value of a key can be accessed using the filename @. If a registry key contains a subkey and a value with the same name foo, Cygwin displays the subkey as foo and the value as foo%val. 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. bash$ echo 'This is "a long" line' > mylist bash$ echo @mylist @mylist bash$ cmd c:\> c:\cygwin\bin\echo @mylist This is a long line