
Om dezelfde dir/file op meerdere plaatsen te kunnen mounten:
- dirs/files moeten herkenbaar zijn als al gemount
  (pDirs moeten gedeeld worden)
- LDir moet voor iedere PDir ook een pointer naar de mount opties hebben
  (aparte structure).
  Als een file eerst gemount was als read-only, maar daarna ook als
  read-write, moet die file opnieuw geopend worden. Als een rw file
  ge-unmount wordt en er alleen nog maar ro mounts zijn, dan mag de file
  opnieuw geopenend worden.


Iedere entry in een LDir moet bij zich hebben:
- een aanduiding van het filesystem type (in de vorm van een PRoot)
- data alleen voor belang voor dat type



Without LDirs:
- DirHandle just has a path to the dir
- FileHandle just has a filesystem pointer and a handle local to that
  fileSystem
- To open a file, the MountTree is checked to determine what fs is relevant

With LDirs:
- locating a directory is faster
- locating a file within a directory is faster
- DirHandle has:
  - a pointer to an LDir
  - a pointer to the mount info (Repository would be enough)
- LDir points to relevant PDirs
- If a PDir is changed, *all* LDirs that refer to it are invalid.
  Either the PDir would have a time stamp (a sequence # is enough),
  or the PDir should have a pointer to all relative LDirs and change then
  when possible. The latter is preferable, as little changes in the PDir
  only require little changes in the LDir.
- when a fs is mounted, the LDirs for the mountpoint (and the dirs in
  between) should be created.


FileTree type




Wanneer er een mount-poging gedaan wordt, moet er nagegaan worden of
er geen aliasing plaatsvindt. Daarom moeten bij een nieuwe mount alle pRoots
die in gebruik zijn nagelopen worden.
root1->handle->pRoot == root2->handle->pRoot && 
root1->handlers->equalNode(root1->handle->native, root2->handle->native)
equalNode zou moeten aangeven of 2 handlers naar dezelfde file wijzen.
Dit zou geimplementeerd kunnen worden met fstat of door in de native handle
een path bij te houden. fstat heeft de voorkeur, waar dit mogelijk is,
aangezien daarmee ook links afgevangen worden (kan niet op Windows).
Als het overeenkomt met een eerdere pRoot, moet die gebruikt worden.
Als de 2e pRoot als RW wordt gemount, met een RW handle, en de 1e pRoot als
een RO handle, dan hebben we een probleem. Het beste zou zijn om de 2e te
gebruiken, maar dan moeten alle handles die binnen de 1e pRoot uitgegeven zijn
vervangen moeten worden (inclusief seek goedzetten). Alles wat indirect
afhangt van die pRoot zou in principe goed moeten gaan.
Voorlopig kan het best om een RW remount niet toe te staan.

Het kan voorkomen dat een pRoot structuur nog bestaat, terwijl er geen mount
info meer naar is. Dit is het geval wanneer er nog handlers naar zijn.
In dat geval dient die pRoot herbruikt te worden bij opnieuw mounten.
Er moet dus een globaal lijstje van pRoots bijgehouden worden.


For absolute paths:
Paths should end on / if the location is meant.
When the dir entry (either file or dir) is meant, there's no / at the end.
Internally, paths don't start with a '/' (unless it's the only character).

uio_addFile moet iets anders
items worden hoe dan ook toegevoegd. Het enige dat een handler kan regelen
is dat er automatisch iets nieuws gemount wordt.
(of niet? zo worden de .zip files zelf niet hidden (valt op te lossen
door behalve type 'file' en 'dir' ook een type 'hide' te maken; mount optie
voor toevoegen)
Bij het vullen van een PDir moeten niet direct de fileType handlers
aangeroepen worden. In plaats daarvan moeten ze worden aangeroepen bij
1) het opvragen van een directory lijst
2) een poging een specifieke directory in te gaan.



When deleting a PDir, it should be verified that the dir was not mounted.
Same for PFiles.


add uio_fdopen
extern uio_Handle uio_stdin, uio_stdout, uio_stderr;
create those on uio_init();
Make function that associates a stdio file descriptor with an uio_Handle.
Can be used for uio_stdin, uio_stdout, and uio_stderr;
Make function 'uio_forwardData()' that reads from one stream and outputs to the
other. Useful for copying stuff.

TODO: dirs that only exist as a mount point aren't shown in dir listings


-= mmap() =-
Simulate mmap(). For stdio fs it can be a real mmap(). For others, it
could be a temporary file which is mmapped (deleted immediately on POSIX
systems where you can have a handle to an unlinked file.
If possible, it could be demand-paged. (reserving a page somehow and catching
sigsegv?)
For operating systems that don't have mmap(), a copy into memory could work.
MS Windows has it's own variant which should be usable
(see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/file_mapping.asp)



-= automounting =-
Put pointer to automount structure in automount structure, so that you can
set the automount structure you want to use for automounted file systems.
Add 'options' argument to uio_MountDir, and 'options' field to AutoMount.
This should be a structure with file-system dependant options.

Say /yabba/dabba/doo is mounted under /zut/, with automounting of .zip files.
What if /yabba/ contains dabba.zip file which contains dabba/doo/bla?
Is it to be used?
No. Automount options count for the mountPoint, not for the physical
structure that is mounted.




Add options for case-insensitivity?



It would be beneficial for speed to open a new handle for a filesystem when a
file inside the filesystem is opened. It shouldn't normally be a real problem,
but for instance when you are reading two files inside a zip file, there will
be a lot of seeking in that .zip file, which is a problem if that .zip file
is itself in a .zip file, and it is not completely loaded in memory.


Locking of files.
Wouldn't even need filesystem-dependant code, though it would be nice for
stdio and perhaps some remote file systems to lock low-level too.


stat on directories?



It might be useful to have an uio_walkPath variant inside the
FileSystemHandler struct, for speed.


Move PRoot->handle to PRoot->native->handle?


PDirHandles and PFileHandles don't add to the reference count of a PRoot.
Currently this is no problem as the handles are short-lived (during
which time the PRoot will be referenced anyhow).
It should either be changed, or documented.


For systems that use the GPDir strucure, PDirHandle has a GPDir directly
in its 'extra' field. This leaves no room for filesystem-dependant data.
It's the question whether that's ever necessary. Probably not.
A way to solve it would be to have a structure with as fields the PDir and an
extra field.
(same for PFileHandle)

Naming not consistent: 'unref' vs 'unInit'.

Do we need a seperate mountRef and handlesRef for pRoot?

Maybe accept NULL as io_DirHandle for a lot of functions which use a relative
path.
uio_OpenDirRelative can then be uio_OpenDir.


