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.

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.