Implementation Notes
Prev | Chapter 1. Compatibility | Next

## Implementation Notes

`chroot` only emulates a chroot function call by keeping track of the current root and accomodating this in the file related function calls. A real chroot functionality is not supported by Windows however.

`clock_nanosleep` currently supports only CLOCK_REALTIME and CLOCK_MONOTONIC. `clock_setres`, `clock_settime`, and `timer_create` currently support only CLOCK_REALTIME.

`close_range` does not support the Linux-specific flag CLOSE_RANGE_UNSHARE.

The Solaris-invented ACL functions `acl`, `facl`, `aclcheck`, `aclfrommode`, `aclfrompbits`, `aclfromtext`, `aclsort`, `acltomode`, `acltopbits` and `acltotext` and the belonging macros and datatypes are defined in <cygwin/acl.h> since they collide with the Linux-compatible POSIX.1e draft macros in <sys/acl.h>. Just include <cygwin/acl.h> if you prefer them over the POSIX.1e functions.

POSIX file locks via `fcntl` or `lockf`, as well as BSD `flock` locks are advisory locks. They don't interact with Windows mandatory locks, nor do POSIX fcntl locks interfere with BSD flock locks or vice versa.

BSD file locks created via `flock` are only propagated to the direct parent process, not to grand parents or sibling processes. The locks are only valid in the creating process, its parent process, and subsequently started child processes sharing the same file descriptor.

In very rare circumstances an application would want to use Windows mandatory locks to interact with non-Cygwin Windows processes accessing the same file (databases, etc). For these purposes, the entire locking mechanism (fcntl/flock/lockf) can be switched to Windows mandatory locks on a per-descriptor/per-process basis. For this purpose, use the call

      fcntl (fd, F_LCK_MANDATORY, 1);

After that, all file locks on this descriptor will follow Windows mandatory record locking semantics: Locks are per-descriptor/per-process; locks are not propagated to child processes, not even via `execve`; no atomic replacement of read locks with write locks and vice versa on the same descriptor; locks have to be unlocked exactly as they have been locked.

`fpclassify`, `isfinite`, `isgreater`, `isgreaterequal`, `isinf`, `isless`, `islessequal`, `islessgreater`, `isnan`, `isnormal`, `isunordered`, and `signbit` only support float and double arguments, not long double arguments.

`getitimer` and `setitimer` only support ITIMER_REAL for now.

`link` will fail on FAT, FAT32, and other filesystems not supporting hardlinks, just as on Linux.

`lseek` only works properly on files opened in binary mode. On files opened in textmode (via mount mode or explicit open flag) its positioning is potentially unreliable.

`setuid` is only safe against reverting the user switch after a call to one of the exec(2) functions took place. Windows doesn't support a non-revertable user switch within the context of Win32 processes.

`vfork` just calls `fork`.

`vhangup` and `revoke` always return -1 and set errno to ENOSYS. `grantpt` and `unlockpt` always just return 0.

The XSI IPC functions `semctl`, `semget`, `semop`, `shmat`, `shmctl`, `shmdt`, `shmget`, `msgctl`, `msgget`, `msgrcv` and `msgsnd` are only available when cygserver is running.

The Linux-specific function `quotactl` only implements what works on Windows: Windows only supports user block quotas on NTFS, no group quotas, no inode quotas, no time constraints.

`qsort_r` is available in both BSD and GNU flavors, depending on whether _BSD_SOURCE or _GNU_SOURCE is defined when compiling.

The Linux-specific function `renameat2` only supports the RENAME_NOREPLACE flag.

`basename` is available in both POSIX and GNU flavors, depending on whether libgen.h is included or not.

`sigpause` is available in both BSD and SysV/XSI flavors, depending on whether _XOPEN_SOURCE is defined when compiling.

`strerror_r` is available in both POSIX and GNU flavors, depending on whether _GNU_SOURCE is defined when compiling.

`dladdr` always sets the Dl_info members dli_sname and dli_saddr to NULL, indicating no symbol matching addr could be found.

`getrlimit` resources RLIMIT_AS, RLIMIT_CPU, RLIMIT_FSIZE, RLIMIT_DATA always return rlim_cur and rlim_max as RLIM_INFINITY, so `setrlimit` returns -1 and sets EINVAL if they are lowered, or returns 0 if unchanged. `getrlimit` resource RLIMIT_NOFILE always returns rlim_cur and rlim_max as OPEN_MAX; `setrlimit` returns 0 sets EINVAL if rlim_cur > rlim_max, does not change the value if it is RLIM_INFINITY, otherwise returns the result from `setdtablesize`. `getrlimit`/`setrlimit` resources RLIMIT_CORE and RLIMIT_STACK return the current values and set the requested values. All other resource arguments return -1 and set EINVAL.

`fallocate` has a few Windows quirks: The FALLOC_FL_ZERO_RANGE operation is NOT atomic. With flags set to 0 and FALLOC_FL_KEEP_SIZE, sparse blocks in the given range are re-allocated as per the POSIX requirements. This re-allocation operation isn't atomic either. Over-allocation with FALLOC_FL_KEEP_SIZE is only temporary on Windows until the last handle to the file is closed. Over-allocation on sparse files is entirely ignored on Windows.

`sched_setscheduler` only emulates API behavior because Windows does not offer alternative scheduling policies. If `SCHED_OTHER` or `SCHED_BATCH` is selected, the Windows priority is set according to the nice value. If `SCHED_IDLE` is selected, the Windows priority is set to `IDLE_PRIORITY_CLASS`. If `SCHED_FIFO` or `SCHED_RR` is selected, the nice value is preserved and the Windows priority is set according to the `sched_priority` value. If the `SCHED_RESET_ON_FORK` flag is set, realtime policies and negative nice values are dropped on `fork`.

`nice`, `setpriority`, `sched_setparam` and `sched_setscheduler` map the nice value (`SCHED_OTHER`, `SCHED_BATCH`) or the `sched_priority` (`SCHED_FIFO`, `SCHED_RR`) to Windows priority classes as follows:

        SCHED_OTHER  SCHED_BATCH  SCHED_FIFO/RR
        nice value   nice value   sched_priority   Windows priority class
         12...19       4...19      1....6          IDLE_PRIORITY_CLASS
          4...11      -4....3      7...12          BELOW_NORMAL_PRIORITY_CLASS
         -4....3     -12...-5     13...18          NORMAL_PRIORITY_CLASS
        -12...-5     -13..-19     19...24          ABOVE_NORMAL_PRIORITY_CLASS
        -13..-19          -20     25...30          HIGH_PRIORITY_CLASS
             -20            -     31...32          REALTIME_PRIORITY_CLASS

The use of values which are mapped to the `REALTIME_PRIORITY_CLASS` require administrative privileges.

Prev | Up | Next
Other system interfaces, some from Windows: | Home | Chapter 2. Cygwin Functions