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.

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.