virtual filesystem layer for the *IX explorer 


author Ruben van Staveren & 
       Martin van Velsen

This document describes the implementation of a virtual filesystem layer as a
plugin for the *IX explorer, a multi platform Windows look-a-like explorer.

 Overview   
         What is a filesystem layer.
 Implementations Details
         How it is done.
 Requirements
         What will I need to in order to write my own plugins
 Feedback
         Let your voice be heared! (bugs/suggestions/FANMAIL!)
 Concept Index
         VFSL Concepts categorized.








Introduction

The Linux (Unix) Explorer is a general filemanager for Unix systems.
It is based on the windows95 version, but with a more unix oriented
look on the file-system. The Linux Explorer tries to give the user
a more user defined view on the complete file/directory tree.  


 VFSL 
Virtual File System Layer

It would be very handy if one could browse through a packed archive, 
or for example a network with ftp. To facilitate that possibility the 
Explorer need to abandon the traditional stat (2),lstat (2), readir(2),
opendir(2) and closedir calls for directory parsing, and the
read(2), write(2), chmod(2), chown(2), open(2),close(2),
unlink(2), link (2), readlink (2), rename(2), calls for manipulation files.

These calls call the native version which are imbedded in the filesystem driver
e.g. the ext2fs for Linux, xfs for Irix, and ffs for NetBSD.

When we define such actions for e.g. a ftp client, or a zip
archive, And implement them in such a way that it is almost 
tranparent to the explorer, we can speak of a Virtual FileSystem
Layer.



VFSL goes technical

As all of the Explorer's internal and external guts are coded in C++ 
you will need a vast knowledge of this beautiful language.

 Plugins 

To give Explorer an arbitrary number of VFSL's we will implement that as 
a plugin.

We will use the shared objects paradigm from SunOS, which is available 
on many platforms nowadays.

Check if you have this available.



SunOS dynamic linking interface

#include <dlfcn.h>

extern void	*dlopen     (char *, int);
extern int	dlclose     (void *);
extern void	*dlsym      (void *, char *);
extern int	dlctl       (void *, int, void *);
extern char	*dlerror    (void);

/* Values for dlopen `mode'. */
#define DL_LAZY		1
#define RTLD_LAZY	DL_LAZY		/* SunOS Compat */



If not, but you know of a alternative aproach that works, contact us.

This will let to create a shared object.

ld -Bshareable OBJS -o lib.s

... more to come...

 Inner working of a VFSL

when a VFSL is loaded, it can be
 The root of a new filesystem hierarchy and listed as a root directory in the left pane
     of the Explorer window.
 The root of a new filesystem hierarchy, but listed somewhere in another filesystem hierarchy

The latter needs a reference to another VFSL. this makes it possible to copy members out of an
gzipped tar on some ftp server. (hmm slow, but hey, it can work :)  )

The only VFSL that may reference the native filesystem, whether it be nfs or a local one,
is the Explorer builtin one.

Others can be too, but can only act as a root filesystem. translucant operations like
browsing an archive on a remote site is not possible then (You have been warned!).

after loading, the Explorer requests the device manager by letting a native "C" function
allocate a C++ object. This object will then give you an handler to read the filesystem with.
There can be only one handler in a filesystem in a window.

Example. A zip archive is an 'filesystem'. you can have more then one of them,
so there may be multiple instaces of them.

Other example: The Explorer has created a new window, for e.g. Drag\&Drop operations.
This require two views of a filesystem and so two handlers are activated.

When a copy operation is performed, it will stay in the active VFSL and will do IO
with the destination VFSL. Selecting a zip archive will copy the archive as it is , and 
will not recusively descent in the VFSL of the archive to copy all members individually.
This is user configureable in Explorer's settings.




 How to write plugins 

When your plugin is activated you should create a copy of your version
of the VFSL Class. For example, let's say you've written a plugin which
attaches a zip archive to a tree point. The user clicks on an archive
and the explorer has been told beforehand by the init function of the
plugin that all files ending in .zip should be handled by your code.

In the header file belonging to the plugin, you've got a definition like:

#include <vfsl.h>

class ZipClass : public VFSL_Class
{
 public:

   int rename (char *);

 private:

};

This definition will inherit the base class VFSL_Class in which the
native file operation code is defined as virtual functions.
U can now redefine your own functions by defining them in the public
part. For example you could write a function called "int rename (char *);"



 Feedback 

Well got some feedback for us ? 
Bugs ? Neat/New features ? Fanmail ?
Don't hesitate and contact us on:
Martin van Velsen vvelsen@@ronix.ptf.hro.nl
Ruben van Staveren staveren@ronix.ptf.hro.nl

If we get flooded by mail we will create a BrintaBBS forum "Unix Explorer".

Shameless Plug: BrintaBBS can be reached at:
(telnet) bbs.hro.nl
(telnet) bbs.ptf.hro.nl
(telnet) brinta.ptf.hro.nl
(http) brinta.ptf.hro.nl