ciopfs - case insensitive on purpose filesystem

ciopfs is a stackable or overlay linux userspace file system (implemented with FUSE) which mounts a normal directory on a regular file system in case insensitive fashion.

The commands below should illustrate it’s function:

mkdir -p ~/tmp/ciopfs/{.data,case-insensitive}
ciopfs ~/tmp/ciopfs/.data ~/tmp/ciopfs/case-insensitive
cd ~/tmp/ciopfs
mkdir -p case-insensitive/DeMo/SubFolder
echo demo >> case-insensitive/DEMO/subFolder/MyFile

At this point your file system should look like this:

`-- DeMo
    `-- SubFolder
        `-- MyFile
`-- demo
    `-- subfolder
        `-- myfile

To avoid any conflicts you should not manipulate the data directory directly, any change should be done over the mount point. All filenames in the data directory which aren’t all lower case are ignored.

If you want to mount the file system automatically at boot time add a line like the one below to your /etc/fstab.

/ciopfs/data	/ciopfs/mnt	ciopfs	allow_other,default_permissions,use_ino,attr_timeout=0	0	0

Note that ciopfs is primarily designed for single user mode. It was originally developed to mount the wine program folder and provide faster case insensitive file access. If you want to give multiple users write access to the same file system, then you have to mount it as root. However, in order to avoid security problems ciopfs will force fuse into single threaded mode and thus hurt performance.


  • ciopfs-0.4 released (2011-06-18)
    • Bugfix in symlink creation
    • Better errno handling
  • ciopfs-0.3 released (2010-09-25)
    • Security improvements: ciopfs forces single threaded mode if the file system is mounted by root and accessible for others
    • ASCII mode should now work (an off by one error which caused a segfault was fixed)
    • Various bug fixes
  • ciopfs-0.2 released (2008-06-30)
    • Unicode support based on glib
    • Better error handling in out of memory situations
    • Various code cleanups
  • ciopfs-0.1 released (2008-05-24)

How it works

ciopfs works by translating every path element to lower case before further operations take place. On file or directory creation the original file name is stored in an extended attribute which is later returned upon request.

This is illustrated below:

getfattr -dR .data
# file: .data/demo

# file: .data/demo/subfolder

# file: .data/demo/subfolder/myfile

Runtime Requirements

If you want the file system to preserve case information you have to make sure that the underlying file system supports extended attributes (for example for ext{2,3} you need a kernel with CONFIG_EXT{2,3}_FS_XATTR enabled). You probably also want to mount the underlying filesystem with the user_xattr option which allows non root users to create extended attributes.

Build Requirements

In order to compile ciopfs you will need the fuse development files, libattr and if you plan to use Unicode characters within file names you will either need glib which is the default or alternatively libicu.

If you want to use neither of those the file system will fall back to libc’s tolower(3) function which is only defined for [a-zA-Z]. Hence, it will only work case insensitively for ASCII file names.

For ease of use the following 3 Makefile targets are supported:

  • unicode-glib (default)
  • unicode-icu
  • ascii

Running one of those followed by sudo make install should do everything that is needed.

Alternatively, you can also use one of the distribution provided binary packages.

POSIX Compliance

ciopfs passes all test of a slightly patched POSIX file system test suite when mounted as root user with the following options:


and $fs set to "ciopfs" in the test suite configuration file. This was last tested with pjd-fstest-20090130-RC.tgz and ext3 as the underlying file system.

Stability and Speed

ciopfs just passes every requested operation to the underlying file system, so in theory it shouldn’t have a negative impact on stability. However, if you find a bug then send me an email with the instruction to reproduce it.

As far as speed is of concern, I didn’t really benchmark or optimize it so far. There is the usual overhead associated with user / kernel space context switches. Furthermore, ciopfs in it’s current implementation uses libc’s malloc/free quite extensively, maybe this could be a bottleneck.


You can always fetch the current code base from the git repository located at Github or Sourcehut.

If you have comments, suggestions, ideas, a bug report, a patch or something else related to ciopfs then don’t hesitate to write me an email.


ciopfs is licensed under the GNU GPL v2.