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.