Movatterモバイル変換


[0]ホーム

URL:


Chapter 3. Using Cygwin
Prev   Next

Chapter 3. Using Cygwin

Table of Contents

Mapping path names
Introduction
The Cygwin Mount Table
UNC paths
The cygdrive path prefix
The usertemp file system type
Symbolic links
Using native Win32 paths
Using the Win32 file API in Cygwin applications
Additional Path-related Information
Text and Binary modes
The Issue
The default Cygwin behavior
Binary or text?
Programming
File permissions
Special filenames
Special files in /etc
Invalid filenames
Forbidden characters in filenames
Filenames with unusual (foreign) characters
Case sensitive filenames
Case sensitive directories
POSIX devices
The .exe extension
The /proc filesystem
The /proc/registry filesystem
The @pathnames
TheCYGWIN environmentvariable
Implemented options
Obsolete options
POSIX accounts, permission, and security
Brief overview of Windows security
Mapping Windows accounts to POSIX accounts
Mapping Windows SIDs to POSIX uid/gid values
Caching account information
Cygwin user names, home dirs, login shells
The/etc/nsswitch.conf file
The/etc/nsswitch.conf syntax
Thepasswd: andgroup: settings
Thedb_enum: setting
Settings defining how to create thepasswd entry
Thedb_home setting
Thedb_shell setting
Thedb_gecos setting
Thecygwin schema
Theunix schema
Thedesc schema
NFS account mapping
Samba account mapping
File permissions
Switching the user context
Switching the user context with password authentication
Switching the user context without password, Method 1: Kerberos/MsV1_0 S4U authentication
Switching the user context without password, Method 2: With password
Switching the user context, how does it all fit together?
Cygserver
What is Cygserver?
Cygserver command line options
How to install Cygserver
How to start Cygserver
The Cygserver configuration file
Cygwin Utilities
chattr
cygcheck
cygpath
dumper
getconf
getfacl
gmondump
kill
ldd
locale
lsattr
minidumper
mkgroup
mkpasswd
mount
newgrp
passwd
pldd
profiler
ps
regtool
setfacl
setmetamode
ssp
strace
tzset
umount
Using Cygwin effectively with Windows
Pathnames
Cygwin and Windows Networking
Creating shortcuts
Printing

This chapter explains some key differences between the Cygwinenvironment and traditional UNIX systems. It assumes a workingknowledge of standard UNIX commands.

Mapping path names

Introduction

The Cygwin DLL supports both POSIX- and Win32-style paths. Directorydelimiters may be either forward slashes or backslashes. Paths usingbackslashes or starting with a drive letter are always handled asWin32 paths. POSIX paths must only use forward slashes as delimiter,otherwise they are treated as Win32 paths and file access might failin surprising ways.

Note

Although the Cygwin DLL supports Win32 paths, not allCygwin applications support them. Moreover, the usage of Win32 pathscircumvents important internal path handling mechanisms. This usageis therefore strongly deprecated and may be removed in a futurerelease of Cygwin.Seethe section called “Using native Win32 paths” andthe section called “Using the Win32 file API in Cygwin applications” for more information.

POSIX operating systems (such as Linux) do not have the conceptof drive letters. Instead, all absolute paths begin with aslash (instead of a drive letter such as "c:") and all file systemsappear as subdirectories (for example, you might buy a new disk andmake it be the/disk2 directory).

Because many programs written to run on UNIX systems assumethe existence of a single unified POSIX file system structure, Cygwinmaintains a special internal POSIX view of the Win32 file systemthat allows these programs to successfully run under Windows. Cygwinuses this mapping to translate from POSIX to Win32 paths asnecessary.

The Cygwin Mount Table

The/etc/fstab file is used to map Win32drives and network shares into Cygwin's internal POSIX directory tree.This is a similar concept to the typical UNIX fstab file. The mountpoints stored in/etc/fstab are globally set forall users. Sometimes there's a requirement to have user specificmount points. The Cygwin DLL supports user specific fstab files.These are stored in the directory/etc/fstab.dand the name of the file is the Cygwin username of the user, as it'screated from the Windows account database or stored in the/etc/passwd file (seethe section called “Mapping Windows accounts to POSIX accounts”). The structure of theuser specific file is identical to the system-widefstab file.

The file fstab contains descriptive information about the various filesystems. fstab is only read by programs, and not written; it is theduty of the system administrator to properly create and maintain thisfile. Each filesystem is described on a separate line; fields on eachline are separated by tabs or spaces. Lines starting with '#' arecomments.

The first field describes the block special device orremote filesystem to be mounted. On Cygwin, this is the native Windowspath which the mount point links in. As path separator you MUST use aslash. Usage of a backslash might lead to unexpected results. UNCpaths (using slashes, not backslashes) are allowed. If the pathcontains 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 beescaped as '\040'.

The third field describes the type of the filesystem. Cygwin supportsany string here, since the file system type is usually not evaluated. So itdoesn't matter if you writeFAT into this field even ifthe filesystem is NTFS. Cygwin figures out the filesystem type and itscapabilities by itself.

The only two exceptions are the file system types cygdrive and usertemp.The cygdrive type is used to set the cygdrive prefix. For a description ofthe cygdrive prefix seethe section called “The cygdrive path prefix”, for a description ofthe usertemp file system type seethe section called “The usertemp file system type”

The fourth field describes the mount options associatedwith the filesystem. It is formatted as a comma separated list ofoptions. It contains at least the type of mount (binary or text) plusany additional options appropriate to the filesystem type. The list ofthe options, including their meaning, 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, for instance) and      is ignored otherwise.  auto      - Ignored.  binary    - Files default to binary mode (default).  bind      - Allows to remount part of the file hierarchy somewhere else.              In contrast to other entries, the first field in the fstab      line specifies an absolute POSIX path.  This path is remounted      to the POSIX path specified as the second path.  The conversion      to a Win32 path is done on the fly.  Only the root path and      paths preceding the bind entry in the fstab file are used to      convert the POSIX path in the first field to an absolute Win32      path.  Note that symlinks are ignored while performing this path      conversion.  cygexec   - Treat all files below mount point as cygwin executables.  dos       - Always convert leading spaces and trailing dots and spaces to      characters in the UNICODE private use area.  This allows to use      broken filesystems which only allow DOS filenames, even if they      are not recognized as such by Cygwin.  exec      - Treat all files below mount point as executable.  ihash     - Always fake inode numbers rather than using the ones returned      by the filesystem.  This allows to use broken filesystems which      don't return unambiguous inode numbers, even if they are not      recognized as such by Cygwin.  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.  nosuid    - No suid files are allowed (currently unimplemented).  notexec   - Treat all files below mount point as not executable.  nouser    - Mount is a system-wide mount.  override  - Force the override of an immutable mount point (currently "/").  posix=0   - Switch off case sensitivity for paths under this mount point      (default for the cygdrive prefix).  posix=1   - Switch on case sensitivity for paths under this mount point      (default for all other mount points).  sparse    - Switch on support for sparse files.  This option only makes              sense on NTFS and then only if you really need sparse files.      This flag is always silently enabled on SSD drives.      Cygwin does not try to create sparse files by default for      performance reasons.  text      - Files default to CRLF text mode line endings.  user      - Mount is a user mount.

While normally the execute permission bits are used to evaluateexecutability, this is not possible on filesystems which don't supportpermissions at all (like FAT/FAT32), or if ACLs are ignored on filesystemssupporting them (see the aforementionedacl mount option).In these cases, the following heuristic is used to evaluate if a file isexecutable: Files ending in certain extensions (.exe, .com, .lnk) areassumed to be executable. Files whose first two characters are "#!", "MZ",or ":\n" are also considered to be executable.Theexec option is used to instruct Cygwin that themounted file is "executable". If theexec option is usedwith a directory then all files in the directory are executable.This option allows other files to be marked as executable and avoids theoverhead of opening each file to check for "magic" bytes. Thecygexec option is very similar toexec,but also prevents Cygwin from setting up commands and environment variablesfor a normal Windows program, adding another small performance gain. Theopposite of these options is thenotexec option, whichmeans that no files should be marked as executable under that mount point.

A correct root directory is quite essential to the operation ofCygwin. A default root directory is evaluated at startup so afstab entry for the root directory is not necessary.If it's wrong, nothing will work as expected. Therefore, the root directoryevaluated by Cygwin itself is treated as an immutable mount point and can'tbe overridden in /etc/fstab... unless you think you really know what you'redoing. In this case, use theoverride flag in the optionsfield in the/etc/fstab file. Since this is a dangerousthing to do, do so at your own risk.

/usr/bin and/usr/lib areby default also automatic mount points generated by the Cygwin DLL similarto the way the root directory is evaluated./usr/binpoints to the directory the Cygwin DLL is installed in,/usr/lib is supposed to point to the/lib directory. This choice is safe and usuallyshouldn't be changed. An fstab entry for them is not required.

nouser mount points are not overridable by a latercall tomount.Mount points given in/etc/fstab are by defaultnouser mount points, unless you specify the optionuser. This allows the administrator to set certainpaths so that they are not overridable by users. In contrast, all mountpoints in the user specific fstab file areuser mountpoints.

The fifth and sixth field are ignored. They areso 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 entirelydifferent (hopefully you know what you're doing), or if you want tomount 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 textmode mount with case sensitivity switched off:

      C:/foo /bar/baz ntfs text,posix=0 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, don't store POSIX permissions in ACLs:

      //server/share/subdir /srv/subdir smbfs binary,noacl 0 0
  • This is just a comment:

      # This is just a comment
  • Set the cygdrive prefix to /mnt:

      none /mnt cygdrive binary 0 0
  • Remount /var to /usr/var:

      /var /usr/var none bind

    Assuming/var points toC:/cygwin/var,/usr/var now also points toC:/cygwin/var. This is equivalent to the Linuxbind option available since Linux 2.4.0.

Whenever Cygwin generates a Win32 path from a POSIX one, it usesthe longest matching prefix in the mount table. Thus, ifC: is mounted as/c and alsoas/, then Cygwin would translateC:/foo/bar to/c/foo/bar.This translation is normally only used when trying to derive thePOSIX equivalent current directory. Otherwise, the handling of MS-DOSfilenames bypasses the mount table.

If you want to see the current set of mount points valid in yoursession, you can invoke the Cygwin toolmount withoutarguments:

Example 3.1. Displaying the current set of mount points

bash$mount  F:/cygwin/bin on /usr/bin type ntfs (binary,auto)  F:/cygwin/lib on /usr/lib type ntfs (binary,auto)  F:/cygwin on / type ntfs (binary,auto)  E:/src on /usr/src type vfat (binary)  C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)  E: on /cygdrive/e type vfat (binary,posix=0,user,noumount,auto)

Starting with Cygwin 3.6.0, thegetmntent(3)function exposes Windows mount points of partitions mounted into a directoryof another drive as if they are cygdrive mounts. This affects the contentof/proc/mounts as well as the output ofmount.

For instance, consider you have two local disks, one containing theC: drive, the other disk has one partition mountedintoC:\docs. The output from mount will now show thismount point like this:

Example 3.2. Displaying Windows mount points as cygdrives

bash$mount | grep cygdrive  C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)  C:/docs on /cygdrive/c/docs type ntfs (binary,posix=0,user,noumount,auto)

You can also use themount command to addnew mount points, and theumount to deletethem. However, since they are only stored in memory, these mountpoints will disappear as soon as your last Cygwin process ends.Seemount(1) andumount(1) for moreinformation.

UNC paths

Apart from the unified POSIX tree starting at the/directory, UNC pathnames starting with two slashes and a server name(//machine/share/...) are supported as well.They are handled as POSIX paths if only containing forward slashes. There'salso a virtual directory// which allows to enumeratethe fileservers known to the local machine withls.Same goes for the UNC paths of the type//machine,which allow to enumerate the shares provided by the servermachine. For often used UNC paths it makes sense toadd them to the mount table (seethe section called “The Cygwin Mount Table” sothey are included in the unified POSIX path tree.

The cygdrive path prefix

As already outlined inthe section called “File Access”, you canaccess arbitary drives on your system by using the cygdrive path prefix.The default value for this prefix is/cygdrive, anda path to any drive can be constructed by using the cygdrive prefix andappending the drive letter as subdirectory, like this:

  bash$ ls -l /cygdrive/f/somedir

This lists the content of the directory F:\somedir.

The cygdrive prefix is a virtual directory under which all driveson a system are subsumed. The mount options of the cygdrive prefix isused for all file access through the cygdrive prefixed drives. For instance,assuming the cygdrive mount options arebinary,posix=0,then any file/cygdrive/x/file will be opened inbinary mode by default (mount optionbinary), and the caseof the filename doesn't matter (mount optionposix=0).

The cygdrive prefix flags are also used for all UNC paths starting withtwo slashes, unless they are accessed through a mount point. For instance,consider these/etc/fstab entries:

  //server/share /mysrv    ntfs     posix=1,acl   0 0  none           /cygdrive cygdrive posix=0,noacl 0 0

Consider a file\\server\share\foo.When opening the file as/mysrv/foo, the flagsposix=1,acl of the /mysrv mount point are used. Whenopening the file as//server/share/foo, the flagsposix=0,noacl for the cygdrive prefix are used.

Note

This only applies to UNC paths using forward slashes. Whenusing backslashes the flags for native paths are used. Seethe section called “Using native Win32 paths”.

The cygdrive prefix may be changed in the fstab file to another pathand mode:

  none /mnt cygdrive posix=1,sparse 0 0

Please note that you cannot use the cygdrive prefix for any other mountpoint to change modes. For instance, these mount table entries...

  none /cygdrive cygdrive binary 0 0  D:   /cygdrive/d somefs text 0 0

...will not open files using the/cygdrive/d pathprefix in textmode by default, but in binary mode per the cygdrive prefixmode. If you want to mount any drive explicitly in another mode thanthe cygdrive prefix, use a different path prefix:

  none /cygdrive cygdrive binary 0 0  D:   /mnt/d somefs text 0 0

To simplify scripting, Cygwin also provides a/proc/cygdrive symlink, which allows to use a fixed pathin scripts, even if the actual cygdrive prefix has been changed, or is differentbetween different users. So, in scripts, conveniently use the/proc/cygdrive symlink to successfully access filesindependently from the current cygdrive prefix:

  $ mount -p  Prefix              Type         Flags  /mnt                user         binmode  $ cat > x.sh <<EOF  cd /proc/cygdrive/c/Windows/System32/Drivers/etc  ls -l hosts  EOF  $ sh -c ./x.sh  -rwxrwx---+ 1 SYSTEM SYSTEM 826 Sep  4 22:43 hosts

The usertemp file system type

On Windows, the environment variableTEMP specifiesthe location of the temp folder. It serves the same purpose as the /tmp/directory in Unix systems. In contrast to /tmp/, it is by default adifferent folder for every Windows user. By using the special purpose usertempfile system, that temp folder can be mapped to /tmp/. This is particularlyuseful in setups where the administrator wants to write-protect the entireCygwin directory. The usertemp file system can be configured in /etc/fstablike this:

  none /tmp usertemp binary,posix=0 0 0

Symbolic links

Symbolic links are supported by Windows only on NTFS and havea lot of quirks making them (almost) unusable in a POSIX context.POSIX applications are rightfully expecting to use symlinks and thesymlink(2) system call, so Cygwin has worked aroundthe Windows shortcomings.

Cygwin creates symbolic links potentially in multiple differentways.

  • The default symlinks created by Cygwin are:

    • special reparse points shared with WSL (on NTFS on Windows 10 1607 or later)

    • plain files with thesystem attribute, containing a magic cookie followed by the path to which the link points.

      Note

      Symlinks of this type created by really old Cygwin releases (prior to Cygwin 1.7.0) are usually readable. However, you could run into problems if you're now using another character set than the one you used when creating these symlinks (seethe section called “Potential Problems when using Locales”).

  • On filesystems mounted via Microsoft's NFS client, Cygwin alwayscreates real NFS symlinks.

  • Native Windows symlinks are only created on filesystems supportingreparse points. Due to their weird restrictions and behaviour, they areonly created if the user explicitely requests creating them. This is doneby setting the environment variableCYGWIN to containthe stringwinsymlinks:native orwinsymlinks:nativestrict. For the difference betweenthese two settings, seethe section called “TheCYGWIN environmentvariable”.On AFS, native symlinks are the only supported type of symlink due toAFS lacking support for DOS attributes. This is independent from thewinsymlinks setting.

    Creation of native symlinks follows special rules to ensure the linksare usable outside of Cygwin. This includes dereferencing any Cygwin-onlysymlinks that lie in the target path.

  • Shortcut style symlinks are Windows.lnkshortcut files with a special header and the DOS READONLY attribute set.This symlink type is created if the environment variableCYGWIN (seethe section called “TheCYGWIN environmentvariable”)is set to contain the stringwinsymlinks orwinsymlinks:lnk. On the MVFS filesystem, which doesnot support the DOS SYSTEM attribute, this is the one and only supportedsymlink type, independently from thewinsymlinkssetting.

All of the above symlink types are recognized and used as symlinksunder all circumstances. However, if the default plain file symlink typeis lacking its DOS SYSTEM bit, or if the shortcut file is lacking the DOSREADONLY attribute, they are not recognized as symlink.

Apart from these types, there's also a Windows native type,so called directory junctions. They are recognized as symlink butnever generated by Cygwin. Filesystem junctions on the other handare not handled as symlinks, otherwise they would not be recognized asfilesystem borders by commands likefind -xdev.

Using native Win32 paths

Using native Win32 paths in Cygwin, while often possible, is generallyinadvisable. Those paths circumvent all internal integrity checking andbypass the information given in the Cygwin mount table.

The following paths are treated as native Win32 paths by theCygwin DLL (but not necessarily by Cygwin applications):

  • All paths starting with a drive specifier

      C:\foo  C:/foo
  • All paths containing at least one backslash as path component

      C:/foo/bar\baz/...
  • UNC paths using backslashes

      \\server\share\...

When accessing files using native Win32 paths as above, Cygwin uses adefault setting for the mount flags. All paths using DOS notation will betreated as case insensitive, and permissions are just faked as if theunderlying drive is a FAT drive. This also applies to NTFS and otherfilesystems which usually are capable of case sensitivity and storingpermissions.

Using the Win32 file API in Cygwin applications

Special care must be taken if your application uses Win32 file APIfunctions likeCreateFile to access files usingrelative pathnames, or if your application uses functions likeCreateProcess orShellExecuteto start other applications.

When a Cygwin application is started, the Windows idea of the currentworking directory (CWD) is not necessarily the same as the Cygwin CWD.There are a couple of restrictions in the Win32 API, which disallow certaindirectories as Win32 CWD:

  • The Windows subsystem only supports CWD paths of up to 258 chars. This restriction doesn't apply for Cygwin processes, at least not as long as they use the POSIX API (chdir, getcwd). This means, if a Cygwin process has a CWD using an absolute path longer than 258 characters, the Cygwin CWD and the Windows CWD differ.

  • The Win32 API call to set the current directory,SetCurrentDirectory, fails for directories for which the user has no permissions, even if the user is an administrator. This restriction doesn't apply for Cygwin processes, if they are running under an administrator account.

  • SetCurrentDirectory does not support case-sensitive filenames.

  • Last, but not least,SetCurrentDirectory can't work on virtual Cygwin paths like /proc or /cygdrive. These paths only exists in the Cygwin realm so they have no meaning to a native Win32 process.

As long as the Cygwin CWD is usable as Windows CWD, the Cygwin andWindows CWDs are in sync within a process. However, if the Cygwin processchanges its working directory into one of the directories which areunusable as Windows CWD, we're in trouble. If the process uses theWin32 API to access a file using a relative pathname, the resultingabsolute path would not match the expectations of the process. In theworst case, the wrong files are deleted.

To workaround this problem, Cygwin sets the Windows CWD to a specialdirectory in this case. This special directory points to a virtualfilesystem within the native NT namespace (\??\PIPE\).Since it's not a real filesystem, the deliberate effect is that a call to,for instance,CreateFile ("foo", ...); will fail,as long as the processes CWD doesn't work as Windows CWD.

So, in general, don't use the Win32 file API in Cygwin applications.If youreally need to access files usingthe Win32 API, or if youreally have to useCreateProcess to start applications, rather thanthe POSIXexec(3) family of functions, you have tomake sure that the Cygwin CWD is set to some directory which is valid asWin32 CWD.

Additional Path-related Information

Thecygpath program provides the ability totranslate between Win32 and POSIX pathnames in shell scripts. Seecygpath(1) for the details.

TheHOME,PATH, andLD_LIBRARY_PATH environment variables are automaticallyconverted from Win32 format to POSIX format (e.g. fromc:/cygwin\bin to/bin, ifthere was a mount from that Win32 path to that POSIX path) when a Cygwinprocess first starts.

Symbolic links can also be used to map Win32 pathnames to POSIX.For example, the commandln -s //pollux/home/joe/data /data would have aboutthe same effect as creating a mount point from//pollux/home/joe/data to/datausingmount, except that symbolic links cannot setthe default file access mode. Other differences are that the mapping isdistributed throughout the file system and proceeds by iterativelywalking the directory tree instead of matching the longest prefix in akernel table. Note that symbolic links will only work on networkdrives that are properly configured to support the "system" fileattribute. Many do not do so by default (the Unix Samba server doesnot by default, for example).


Prev   Next
Customizing bash Home Text and Binary modes

[8]ページ先頭

©2009-2025 Movatter.jp