storage

The ability to mount filesystem's directory structure 'over the top of' existing mounted filesystems would allow for a number of simplifications for Haiku users' systems.

Details

Traditionally mounting a filesystem on a specific directory results in the new filesystem 'overriding' the specified directory, effectively hiding the original directory's contents. This restriction could however be lifted, allowing for layered, or union, mounting of systems.

When mounting filesystems the system will keep an ordered list of mount points. When file/directory/etc access occurs the system will traverse the mount list attempting to find a matching filesystem object in each in turn. The first match found is the one on which the system will act. Therefore, if there are two (or more) matches for a specific object the system first on the mount list will be used.

If the operation being attempted is that of file creation the system should create the file on the first read-write system found.

Usage

For Haiku users the system would keep a user specific set of directories with which it could overlay the system directories. Eg, A user may desire management of their own font directory. This directory could be mounted during login over the system font directory, thus removing the need for management of separate search paths.

The system would allow much freedom in areas traditionally protected due to permission constraints also. For example, installation of new software for a specific user is generally a difficult operation without resorting to increased privileges. However with layered file systems a user would have a (possibly blank) application directory mounted over the system application directory. Again doing away with multiple search paths and keeping the system much more cohesive.

Issues

• More specifics on handling of specific layers and filesystem operations?
• Does this system obfuscate the system internals where they are working adequately already?

File systems could benefit by adding functionality which would allow files to behave differently based upon which user is currently reading them. Objects could have different contents, permissions and attributes.

Details

A file/user polymorphic file system would give file system objects the ability to behave differently, or effectively be different, for each user. It would allow all file information to be selected dynamically based upon entirely upon the current user. In more general terms, a file which is polymorphic could appear completely different, in terms of data content and meta-data, when viewed by different users. The only detail necessarily the same would be the file path.

A short, and incomplete, list of file information that could possibly be managed via this process is,

• Contents, i.e. The actual file data
• Attributes
• Permissions

Foreseen difficulties mainly lie in the area of administration. It is difficult to determine how an administrator would be able to modify a given user's files if it was polymorphic. This could affect operations such as backups negatively. Also, depending on the specific implementation, it has been suggested that there could be difficulties in allowing multiple users access to the file system.

A possible implementation that has been suggested is to implement polymorphic symlinks whose target changes depending on the current user. This would fit nicely with existing file system methodologies and hence be one of the most transparent implementations.

Primarily the benefits of polymorphic file systems lie in the reduction of complexity from the user and application's perspective. They no longer need to take into account whether the system is multi-user or which user is logged in. There is a single file hierarchy for all cases which, without application or user intervention, changes to suit the scenario. However care must be taken to not hard code too many paths. Functions such as find_directory (located in the storage kit) should still be used to find specific directories for application usage as much as possible.

Direct uses are many and varied. The most popular of which is the ability to have the user's home directory managed via a polymorphic entry. This would also simplify the implementation of quick user switching similar to XP and Panther. Also, application settings files could be stored with the application itself, simplifying the copying of the entirety of a given application and its environment.

Resources

• Implementation of polymorphic symlinks with Linux and ext2

Storing information about devices as attributes in the relevant areas of the devfs could allow much simpler (and more powerful) access to device specific data.

Details

There are many items of information regarding physical and virtual devices that require specialised APIs for querying. In order to implement this system an additional set of driver hooks could be added to retrieve the data. It has been suggested that using this method, driver complexity and extensibility (regarding PCI IDs) could be improved.

It would be possible, if the required functionality were in place and attributes present, to utilise a kernel enforced naming convention for devfs publication. Eg, "this is a IDE raw disk node, on the 1st bus master device" could be used to create a kernel defined devfs path.

Applications

Many applications exist such as,

• Video card frame buffer address
• Manufacturer ID and device string
• Ethernet MAC address

In addition to these examples the use of queries would provide an extremely powerful user interface to the hardware information.

This proposal suggests an attribute based system to label files as referencing other files in order to allow queries to utilise inter-file relationships.

Details

Currently files whose contents reference other files on the local system can only be found through interrogating the file's data or through other similar mechanisms requiring some insight into the file data. It is proposed that a system wide set of attributes be used in order to build relationships.

Each file which is referred to is given a unique ID which remains constant across all filesystem operations (specifically moving) in order to preserve relationships. To create the relationship a file will have a special 'ParentID' attribute set which contains this key. In order to find all file relationships a query can be constructed which matches these keys.

This system allows for more general tree structures of references. An application can thus utilise queries to work its way up the tree finding required relationships as needed. The application of this proposal would be best benefited through modifications to Tracker in order to allow visualisation of this tree structure; The primary benefit is that of more logical data organisation without resorting to specialised applications. A great example of this at work would be email 'conversation trees'.

Issues

• Distinct key types or one key type was never decided. Ie, whether to use recipient and sender IDs or just generic IDs
• How are keys generated?