For example, we could implement what can generally be called an indexed filesystem. This shares the characteristics of the .tar and VFNews filesystems. In an indexed filesystem, you create a symlink that contains the information about which filename we are accessing, the start offset, and the size.
For example:
# ln -s @/etc/data:1024:44 spud
This creates a symlink with the value @/etc/data:1024:44. If a regular filesystem tried to open this, it would yield an ENOENT immediately, as there is no path that starts with an at-sign.
However, since we control the c_link() function call, we can look at the value of the symlink, and determine that it's something special. The @ is our escape character. When you process the c_link() function call, instead of creating a symlink as you would normally, you can create anything you like. In this case, we'd create a plain, ordinary-looking file, that internally had the information that we passed to the symlink.
You can now see how this worked in the .tar filesystem — the information that we stored in the extended attributes structure told us the name of the on-disk file (the .tar or .tar.gz file) and the offset into that file where the data begins; the regular (non-extended) attributes structure gave us the length.
It's a “simple matter of programming” for you to do the same thing with the indexed filesystem. The only funny thing that happens, though, is that after we create the special symlink, the file looks like a regular file:
# ln -s @/etc/data:1024:44 spud # ls -lF spud -r--r--r-- 1 root root 44 Aug 16 17:41 spud
Normally, you'd expect to see:
# ls -lF spud -r--r--r-- 1 root root 18 Aug 16 17:41 spud@ -> @/etc/data:1024:44
but since we converted the symlink to a plain file in the c_link() function, you'll never see that.