-
Notifications
You must be signed in to change notification settings - Fork 5
Home
This documentation is in progress
The state mentioned below is what the state is at the time of this writing. This API is only in its infancy, and what will be supported will evolve; both to match the author's needs and yours, so if you have requests or even better, implementations for new features, do not hesitate.
First of all, it should be noted that the notion of a "hard link" itself is mistaken; in Unix systems, the basic unit is not a file or directory but an inode; and the fact that a file has an entry into a directory is what a link is; this link happens to have a name, and that is what is commonly known as a "file name".
As to symlinks, well, they are just a type of inode which are not "files". They also have links. And directories are yet another matter.
Anyway. This package has no notion of inodes. Therefore it does not know about links. And it has no symlink support either. You only have the notion of "directory" and "file".
There is the notion of attributes for file stores in the API; this package does not support this yet.
This is by far the most common case. Many stores and root paths are indeed useful for native filesystems (Unix systems for instance will have one store per mount point; Windows systems have several root paths, one root path matching a "drive", c: and so on).
But for custom filesystems, which will very often be over network services, such notions are not necessary.
You don't have to care about implementing Path, all is done for you already; all you have to do is ensure that the correct path elements implementation is used. This package provides the most common use case (a Unix-like path implementation).
In the same vein, this package uses a generic FileSystem implementation so you don't have to care about implementing this abstract class at all.