Cygwin Issues

From OSDev Wiki
Jump to navigation Jump to search

This page is under construction! This page or section is a work in progress and may thus be incomplete. Its content may be changed in the near future.

Known Issues for Cygwin

Experimental blackboard to get it into the official docs then. Only a few hardcore developers will be able to verify these issues.

I found no document where missing POSIX functionality is listed and where other non-POSIX but expected typical UNIX functionality and/or behaviour are different or missing. The user guide is a bit short on that.

This should help UNIX developers and should go the the official cygwin user guide (or FAQ?) then. Unsolved issues (such as some Ghanshyam items) should go to bugzilla then.

Please fix add or fix as approriate.

Known Issues

First see the user-guide and ff. for the definitive answers. But some of these answers are known and verified to be outdated.

Strictly NON-POSIX

  • fopen(): Ghanshyam listed several NON-POSIX issues starting with
Note on "fopen is successful even if search permission is denied": this isn't a Cygwin issue. Windows disables access checks for directory traversal by default, by granting and enabling the ~SeChangeNotifyPrivilege privilege for all users. Revoke this privilege to your user or group if this is a problem.
Update: Since 1.3.14 cygwin honors directory traversal security as in POSIX. Turn it off via CYGWIN=notraversal to get back the Windows behaviour not to check all upper dirs for proper perms.
  • sysconf():
  • strftime():
  • sigaction():
  • struct lconv *localeconv:
  • clock_getres() missing though _POSIX_TIMERS is defined:
  • symlink(2) is not atomic:

TODO: find and document more problems.

Unexpected Behaviour

Filesystem Related

case-insensitive search

Windows filesystems are usually case-insensitive in search, but case-preservant (I know of 5 windows fs in general use, NTFS5 as best, a new one on the horizon). For POSIX compatibility there's no optional option or flag to restrict searches (open,fopen,readdir,unlink,rename,...) to be case-sensitive. You can only tell your filesystem to be case-sensitive (somewhere in the registry, which is not recommended and unrealistic), use special cygwin managed mounts (mount -o managed) or check case-sensitivity explicitly in your code. Best is to avoid such issues beforehand, not allowing only case-different filenames.

But with user-created plugins it will get complicated.
TimRobinson: it's possible to get Windows to use case-sensitive lookups

at the kernel level, which is how psxss.exe and Interix work. But doing so can confuse Win32 apps, which clearly don't distinguish case.:

Exercise: Get hold of the Windows Resource Kit. Create a two files file

using the cat.exe included, whose names differ only by case. Delete them by name using the del command.

pathname resolution

Cygwin is taking too much liberty when resolving paths with .. in them, as of 1.5.14. POSIX requires that the pathname before the .. exist, and if it is a symlink, that it is resolved, before going to the parent directory. Cygwin is blindly collapsing dir/.. into nothing, without first verifying dir, in violation of POSIX. (Eric Blake) It will probably keep this behaviour due to performance reasons. (cgf)


  • unlink isn't atomic (as on other platforms also)
while (!unlink(..) or end-of-waiting()) { sleep; }
On cygwin unlink() is deferred to the end of the process, when unlink fails because of locks or delete on close (ERROR_SHARING_VIOLATION).
  • unlink a file and subsequent creation of a new file in the same location is not supported.
  • unlink(2) doesn't do traverse security checks:
cygwin unlink() still has the POSIX bug I reported earlier where calling unlink() on a file in a directory with no write permissions still removes the file, thanks to the underlying Windows implementation. Worse, because the directory has no write permissions, you can't directly re-create a new file to replace the one that was erroneously deleted. But Chris already argued that checking for write permissions on the parent directory as part of every unlink() call would slow down the common case. - EricBlake
  • "delete on close" (unlinking an open file) is supported.
(definitive answer: => pierre)

Passing file descriptors


  • hardlinking directories is only available to the superuser
ln -d, ...
  • *junctions* (NTFS4 directory mount points and NTFS5 volume mount points via Reparse Points) are almost equivalent to symlinks, but symlinks are implemented in cygwin differently and slower and do work on filenames and non-local volumes also.


  • Mounting filesystems and devices are not supported.
The /usr/bin/mount syntax is similar but different to your favorite mount. See mount -m.
  • /etc/mtab is not linked to /proc/mounts.
/proc/mount is not yet implemented, but a few other procfs files are:
 $ ls /proc
<cyg-pids/...>  cpuinfo  meminfo registry/ uptime loadavg  partitions  stat  version 

Device limitations TODO

Explain about our device mapping, special block/char devices, other magic devices like sockets, fifo's, ... /dev/dsp and other audio devices do work. Serial devices have some known limitations. Igor's /usr/sbin/ helper (ml-url?)

Special filenames


  • using (esp. unlinking) "NUL" and other special filenames is problematic (see FAQ and windows-special "\\.\" and "\??\" path-prefixes on Windows).
"DEL \\.\c:\somedir\nul"
There was a cygwin1.dll patch by Pierre which allows deleting such accidently created files.


See user guide ( : [ setfacl | ] / [ getfacl | ] )

cygwin ACL's are not 1:1 mapped to windows ACL's, esp. for inherited directory permissions. (?)


(definitive answer: => corrinna)



  • sync() is a no-op (although it's possible on Windows, see [1] - the part beginning with "To flush all open files on a volume" - and [2] for a tool that makes use of it), and as specified by the standard it's unclear whether it's even supposed to do anything (all cache managers eventually flush dirty pages...).
  • fsync() works as expected.


See,, sysbash, network shares, samba, windows profiles, ... Of course cygwin is entirely insecure.


  • UNIX root uid is 0, Windows SYSTEM uid is 18.
  • cygwin cron usually runs as user SYSTEM and therefore ...
(network shares, file permissions, ...) TODO
  • TODO: setuid,setgid file permission flag and workarounds.
  • setuid()/setgid() process workarounds.
  • TODO: setsid()/setpgid(): ??
  • TODO: su, sudo vs runas ...
  • TODO: login limitations


See the user-guide on fork, IPC, ... (definitive answers: => cgf)


Works as expected.

See and


  • Unfortunately cygwin must use seperate PID's than the underlying windows PID's. is outdated. (cgf)


  • Requires the *cygserver* daemon (which requires the string "server" in $CYGWIN).
ipc-daemon2 is outdated and should be uninstalled. Unless you still use postgresql 7.4.3 or other dependent packages.
  • IPC is not fully supported on Win95 yet, due to known cygserver problems.
TODO (fixed in which snapshot, when?)


1.5.11 was rather unstable compared to 1.5.10.

  • -lpthread is supported by cygwin1.dll, libpthread.a is just an import library.
  • PROCESS_SHARED objects may not work (?, R.Collins, April 2001)
  • pshared mutexs (?)
  • signals cannot interrupt semaphores: semaphore::_trywait
  • as always: The latest snapshot might have fixed it :)


See and

Use gcc -shared or libtool, or the older helpers dlltool, dllwrap.

  • All exported symbols must be relocatable and known at compile-time.
Unless on unix, where they will be resolved at load-time ("lazy").
  • Building a .dll might require more steps than building an .so
(unless you use the simple gcc -shared of course). Google for "Microsoft designers must have been on crack", might need special MSVC-like __declspec IMPORT/EXPORT declarations, but better use the linker methods.
We use specially named import libraries named like "lib<package>-version>.dll.a", The shared libs like "cyg<package>-<version>.dll", and must reside in the PATH!
Most packagers just forget the required -no-undefined libtool switch.
DATA sections (structs, classes) to be exported from DLL's will best work with this linker switch: -Wl,--enable-runtime-pseudo-reloc
  • Importing symbols from .exe's will not work, unlike on linux or solaris.
you can only import from dll's.
See and
  • Lazy linking is not yet supported by GCC.
See wine and MSVC. (Info for windows folks only)

getloadavg() missing

  • getloadavg() is still a noop on windows. No one came up with a comparable solution yet.
It is used by make, xemacs, top, ...


/bin/sh really is ash (a smaller bourne shell). On linux it's usually /bin/bash. There are subtle syntax differences.

See also select() above.
  • bash PID reuse problem was fixed by bash-2.05b-16.
(TODO: ml-url)
  • Foreign characters support:
cygwin does NOT support UTF-8 nor UTF-16 yet, since newlib doesn't support it. Use better terms, CYGWIN="codepage:oem"

Other magic good to know

  • *winsock* requires the 'SYSTEMROOT' environment variable setting. CGI might fail. Fixed since 1.3.14. Reason: cygwin uses the windows socket library.
Workaround for Apache: ~SetEnv SYSTEMROOT "<path-to-c-windows>"
  • setup --help (as of v2.427) does print its options, but to ./setup.log not to STDOUT.
setup --help; tail setup.log