Windows-Friendly Cygwin Paths

Not too long ago, I ventured into using Rake for my .Net project builds.  Given that my shell preference on Windows is Cygwin’s bash port (via the excellent mintty terminal), I tend to prefer installing the Cygwin ruby package rather than using the RubyInstaller for Windows.

One issue I ran into, however, was that the absolute paths generated under rake resolve to /cygdrive/c/ by default.  This isn’t an issue when calling applications compiled for Cygwin, but they pose a problem if you need to pass an absolute path as a parameter to commands like MSBuild.  One way to resolve this problem is to create an NTFS mount point which mirrors a path that Windows executables can resolve.  Here’s how:

Open up the file /etc/fstab which configures the mount table under Cygwin.  Add a line similar to the following:

C:/projects /projects ntfs binary,posix=0,user 0 0


This mounts the C:/projects folder (where I do all of my project development) as /projects.  Note that the mount point must be named the same as the actual physical NTFS path.  After restarting the shell, the new mount point will be available.  This can be verified by issuing the mount command:

> mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/projects on /projects type ntfs (binary,posix=0,user)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type iso9660 (binary,posix=0,user,noumount,auto)
G: on /cygdrive/g type ntfs (binary,posix=0,user,noumount,auto)
H: on /cygdrive/h type ntfs (binary,posix=0,user,noumount,auto)
I: on /cygdrive/i type vfat (binary,posix=0,user,noumount,auto)

Since Windows accepts the forward slash as a directory delimiter and considers drive letters to be optional, expanding a relative path under the NTFS mount point will render a path that can be correctly interpreted by Windows executables.

About Derek Greer

Derek Greer is a consultant, aspiring software craftsman and agile enthusiast currently specializing in C# development on the .Net platform.
This entry was posted in Uncategorized and tagged . Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Andy

    You could also just install Cygwin into C:\, thereby making / identical to C:\. Advantage: easier mental switching between Cygwin and Windows paths. Disadvantage: Unix and Windows directories get mixed up at the top level (although that’s quite similar to what you’d get on a Mac), and you have to trust the Cygwin package maintainers not to accidentally clobber something in the Windows directories.

  • Where Cygwin gets installed wouldn’t affect the default mount table settings. If you were to install Cygwin in the root then you’d still find that working in C:/Projects would resolve to /cygdrive/c/projects.

  • A neat trick. I just do a $( cygpath -w ) when calling out to Windows apps though.

  • Andy

    No, it would be at /Projects, alongside /bin, /usr, /Windows, /Users, … .

  • @Eric Yeah, that works if you don’t mind writing Cygwin-specific scripts, but when working on a team where not everyone uses Cygwin or for any open source build scripts this isn’t a viable option.

  • @Andy I stand corrected. This works as long as the paths you’re referencing are on the same drive as the one you’ve installed Cygwin in the root of, but this wouldn’t suffice if expanding relative paths for another drive (e.g. developing in X:/Projects/). In this case, you’d still need to follow the approach outlined here. This also isn’t going to be a practical option for people already using Cygwin, as most wouldn’t want to reinstall/copy all there files over for this purpose.

    Interesting find, but ultimately my recommendation would still be to set up an explicit mapping in the mount table to avoid the consequences that installing Cygwin in the root would lead to.

  • Andy

    All fair points.