That would be super obnoxious. You:

• Wouldn’t be able to see them all at once
• Wouldn’t be able to place comments explaining why things are set the way they are
• Wouldn’t be able to have documentation on what commands do, or what possible options are right in the configuration
• It would make backing up/version controlling your configs more obnoxious.

Using a library to store and read stuff in XML (ugh) or JSON or INI files is so easy there is no excuse to come up with other stuff.

Filesystems are meant to store and organize files. Don’t abuse it and come up with a half-baked configuration alternative when there are plenty of configuration libraries available.

This is a perfectly fine way of representing tree-shaped data. A file system is a tree database, why re-implement one on top of it?

The most well-known implementation of this idea is the Windows Registry. Its main flaw is that it implements a filesystem alongside the filesystem and doesn’t support the filesystem API, which means you can’t use filesystem tools such as find or grep on it.

Elektra is a project which implements a global configuration key-value database similar to the Windows Registry in a portable manner. It uses a storage format very similar to the one you describe.

The Linux sysfs virtual filesystem which is used to both expose data about the kernel object graph and change settings also uses a “one-value-per-file” format and uses symlinks extensively to represent graph-shaped data.

The Gatling web server even uses filesystem metadata for configuration. Here’s how you configure two virtual hosts:

mkdir www.example.com:80
mkdir internal.example.com:8080

Here’s how you configure a redirect:

ln -s http://www.google.com/mail gmail

Here’s how you tell Gatling that a file is a server side script, i.e. that it should be executed and not served:

chmod +x script

Here’s how you tell Gatling to serve or not serve a file:

chmod o+r serve_this
chmod o-r dont_serve_that

Gatling appears to have been inspired by qmail.

In addition to an excellent answer provided by @whatsisname:

• It won’t be possible to make two elements of the same name;
• It won’t be possible to share the config;
• It won’t be possible to make custom order of elements;
• Different file systems have different limitations as per file names. They also have reserved names, like CON or NUL for Windows;
• Also, file systems may be case-sensitive or not.

I completely concur with the idea of using a ready-made library for working with configuration files.

Regarding your concern of storing large chunks of binary data, most database-driven config libraries provide with that feature. If chosen a library that doesn’t, using a file/directory reference plus individual binary files seems to be the best idea.

This has in fact been done. For example, qmail control files are individual files that contain a single line with the configuration setting.

The fact that this is not a very popular method of configuration is supported by reasons given in other answers to this question.

Here are some considerations not mentioned so far, that may or may not be relevant, depending on the application you would want to use this for.

Integrity check of the configuration

With a single config file, take a cryptographic hash. Done. If it differs next time you read the file, then you know it was manually modified or got corrupted.

With a filesystem based config, you need to traverse the whole tree, reading items in a specified order before feeding them one by one to the hash. Not only the file content, but also the directory and file names. Quite some things to do.

Related to this,

Robustness

Even if you have integrity checks, then there is so much more that could go wrong within a file system. Just think about a user looking through the files, moving some files/directories to other locations, with his uncareful mouse movements and a nervous finger.

How would you handle a link to a parent directory that throws you into an infinite loop when you traverse it unchecked. With the right corruption that is not checked by your application, it may as well be rendered completely broken, requiring an uninstall, manual cleanup and a reinstall.

A backup of a corrupted config file is so much easier to restore.

Talking about backups,

Power users and administrators

What may they want to do?

• Modify it in ways that are useful, but not possible with your builtin configuration dialogs.
• Backup and restore of the config.
• Export/import of the config.
• Transfer the config to a friend or to their second machine.
• Rollout a mandatory config to a large number of machines and users.

With a single, text based config file, everything you need is already built into the OS: Copy, move and rename of files, a text editor, copy and paste. The transfer is as easy as attaching a file to a mail.

With the filesystem, everything that is not provided by your application is hard to do. Manually modifying a text option? Better take care not to add an additional End Of Line. Modifying a binary option? Hmm, hex editor?

Transfer the config by mail? You need additional tools: Build a zip file and attach it. Then hope that the binary options inside won’t trigger the mail virus scanner and that it gets through.

For all practical purposes, a filesystem based config is as good as a black box for a non-programmer.

EDIT: Cluster size

A separate file for each option may use quite a lot of hard disk space. When each 5 byte option eats a full 64KB cluster, and you have a lot of them… Do the math.