Extra directory entry contents


Owner:

  Used for quotas and access control; valid on files and directories.


Invisible bit:

  If set, the Filer will not display an icon for the object; valid on files
  and directories.


Link bit:

  If set, the Filer will display the object's icon modified in some standard
  way (eg with a red arrow across it) to indicate the existence of an
  indirection of some kind. This bit would be set for "link objects" (see
  later).


Timestamps:

  Support "date/time last accessed" and "date/time created" as well as 
  "date/time last modified"; this is in line with Unix.


Typed directories:

  The filetype field of a directory will be interpreted by the Filer as
  follows:

      type      interpretation

     0 (say)    directory   (as at present)
     1 (say)    application (even if name does not start with "!")
      <xxx>     document of type <xxx>

  [What happens if the filetype identifies an IFS? - presumably it's an
   error, in the same way that !Edit will refuse to process a directory
   even if its filetype is "Text".]

  This makes it possible to present a directory as a single object to the
  user - for example, treatment of current Impression documents would benefit
  from this.


IFS can return filetypes:

  The above proposal breaks down if the directory is an emulated directory;
  that is, if it's really an image file. This is because the type of the
  image file determines the IFS to be used to emulate the directory, and
  there's nowhere to store the type of the emulated directory.

  A solution to this is to define a new interface between FSw and an IFS to
  read the filetype of the emulated directory. FSw will use this interface
  whenever it needs to know the type of the directory - it is transparent to
  client applications, such as the Filer.

  The IFS has to store the emulated filetype somewhere - perhaps in a special
  file, or as the type of a special file, or inside the image itself.

  A bit inside the Image Filing System Information Word can be used to
  distinguish between those IFSs which support the new call and those that
  do not; in the latter case, FSw will always return the type as "directory".

  [This approach means that image files are treated as their emulated
   directories under *all* circumstances. For example, a MyFS image file
   would be presented as a directory icon, and dragging this icon to another
   Filer window would cause a hierarchical copy of the files within the image
   to take place. This is *not* what happens at present.]

  [Are there any other attributes which need to be duplicated in this way?
   Ownership and access controls can probably be assumed to be the same for
   the image file and the emulated directory.]
  

Symbolic links as an IFS:

  A symbolic link to a directory can be (partly) implemented as an image file
  of type DirLink whose content is simply the name of the directory.

  The corresponding IFS - DirLinkFS - will translate file names using the
  image file's contents, and will access the referenced directory to find out
  its real type to return as the emulated directory's filetype. [This may
  result in further nested calls of DirLinkFS.]

  But true transparency for symbolic links is probably not user-friendly:
  should "copy" copy the referenced directory, or just the link? What about
  "delete"?

  One way to manage this is to define symbolic links as a new "object type",
  so that we now have files, directories, images and links. The Filer can
  now take appropriate action according to an object's underlying type.

  [This change could well upset pre-existing programs which expect only to
   see objects of type 1, 2 and 3.]

  [There is still the problem of how to access a symbolic link as its image
   file instead of as its emulated directory.]


IFS can intercept operations on the image file itself:

  The idea here is to make it possible for a module to present one file as
  another one. Examples are:

    - compressed contents
    - encrypted contents
    - symbolic link from one file to another file

  Another bit is allocated in the Image Filing System Information Word to
  indicate that the IFS can intercept such calls.

  If this bit is set, client requests to open the file are passed through to
  the IFS, as are requests for the file's filetype; this means that the IFS
  can implement, say, a compression technique, whereas the user/client can
  continue to set the emulated file's filetype as appropriate.

  [To create a compressed file, the client must:

     - create a file
     - set it's type to Compressed

   From now on, accesses to the file will be intercepted by CompressFS, and
   so - for example - its type will be returned as some default built-in to
   CompressFS - say Data.

   The client can now reset the type as desired, say to Text.

   There is no way to access the underlying file - other than killing the
   CompressFS module.]

  [Presumably the emulated file's filetype can identify a further IFS which
   is capable of intercepting image file operations - thus making it possible
   to have encrypted compressed files ...]

  [It would be nice if a single module could behave both as a normal IFS and
   as one which intercepts image file operations; this would make it possible
   for a single IFS to implement symbolic links to both files and
   directories.]


Notes:

  No "application bit" is necessary; instead, we allocate a filetype to mean
  "this directory is an application".

  Support for "workgroups" is still to be determined; I have asked KR and
  MN-S for their input. Possibly a "reserved" bit (with the name of the
  reserver - cf source control systems) might be worthwhile.

  At present, I think FSw opens an image file when it first needs to, and
  then leaves it open "for ever" (ie until shutdown - complete or of the
  particular IFS). This might not be acceptable in a world where IFSs are
  used more extensively, so some changes would be necessary here.
