Extra directory entry contents


    Original notes from first discussions with JRe on 15-Feb-94
    Remarks indented by "* " added after second discussions with JRe on
     17-Feb-94.
    See "newattrs2" for next version.


Owner  -  yes; used for quotas and access control; valid on files and
  directories.


Invisible bit  - yes; valid on files and directories; if set, Filer will not
  display icon for the object.


Execute bit - yes; intention is that files which have no other access bit set
  can still be loaded for execution, even though they cannot be read [but I
  can't see how RISC OS can ever implement this - perhaps this bit has no
  meaning for files]

  For directories, this indicates to the Filer that the object is an
  application - so apps no longer need to be called !<name>.

* If we have typed directories, just allocate one of the filetypes to mean
* "this is an application" - so no need for this bit (worthless on files).


Support for "workgroups" - tbd; must ask KR and MN-S. Possibly a reserved bit
  and the name of the reserver.


Timestamps - support date last accessed and date created as well as date last
  modified. This is in line with Unix.


Directories as files:
  The idea is to allow an application to implement a document format as a
  number of files held in a directory structure, whilst at the same time
  making sure that the assemblage appears as a single object to the user.

  Current Impression directories are an example.

  To achieve this, we need:

    - a "dirisfile" bit which instructs the Filer to present the directory
      as a file.

    - a "filetype" field for the directory (this already exists)

  When the "dirisfile" bit is set, the Filer presents the object as a file of
  the given "filetype", and FilerAction copy, delete, move etc. treat it
  accordingly. In particular, any access-setting will be treated as recursive
  so that the directory and all the files within it receive the same access
  permissions. [There is scope for great confusion if individual files within
  the directory are given different owners/access bits - but this is true of
  Impression documents at present in any case.]

  But [presumably] shift-double-click will open a directory viewer on it.

  FileSwitch operations all treat it as a directory - that is, its object
  type is 2 [file=1, dir=2, image=3].


Files as directories:
  This is already achieved by Image Filing Systems - or, to be more precise,
  a file can be treated as the *root* directory of an image filing system.

  This distinction is important, because root directories do not have any 
  attributes associated with them. [Experiment shows that FileCore root
  directories always appear to have just the "locked" bit set and nothing
  else; on the other hand, an NFS mount point ("NFS::mail.$") behaves just
  like any other NFS directory.]

  One consequence is that this technique *cannot* be used to represent a
  "file as a directory as a file"; that is, we can write an IFS that
  implements an Impression directory as a single file - but cannot then treat
  the resulting "file as a directory" as if it were a file of type "Impress".

  This is a pity; it would be nice to have, say, an IFS which is appropriate
  for Impression-like "compound" documents - and then a number of different
  applications which use it to implement their own specific document formats
  (eg Impression, Advance, Schema, ...).

  Note that it also appears that "files as directories" cannot be RISC OS
  applications - eg double-clicking on a DOSFS image file called !Drive_C
  simply opens the root directory rather than running any contained !Run
  file.

* This is a "bug" (actually a design decision) in the Filer; it can be
* "corrected" without difficulty.

  One workaround is to accept the restriction that only non-root directories
  can be represented as files, and simply to add an extra level of structure:

                      report          -  a typed directory  ("dir as file")
                        |
                        |
                     container        -  optionally an image file
                        |
                   -----------
                  |   |   |   |
                 f1  f2  f3  f4       - component compound document files

  The Filer will present "report" as a file of type "Impress", say.

  Impression will refer to files "report.container.f3" - which will work
  regardless of whether "container" is a directory or an image file of type
  DocFS, say.

* This workaround does not allow, say, a Compound Document Format file to be
* moved transparently from a DOS machine to a RISC OS machine. This would be
* a very nice feature - Colton Software could well make use of it.


Files as files:
  An IFS is a module which registers a filetype with FileCore so that files
  of that type are interpreted as directories. The idea here is to provide an
  analogous facility to allow a module to present one file as another file.

  For example, a module could be written to compress the data in files, or to
  encrypt a file.

  There is a problem here analogous to the one identified above - such a file
  must have as filetype a value which identifies the module to process it;
  how is access to its emulated filetype achieved? (The directory-as-file
  workaround seems particularly heavy-handed here)


Extra filetype field:
  Here is a sketch of a possible solution to the problems identified above;
  it requires an extra filetype field which I shall call the doc_file_type.

* This could be supplied by the IFS or file transformation module; this has
* the advantage that no extra interface is needed (and space does not have to
* be reserved for the new attribute in every directory entry) - and the
* disadvantage that directory enumeration will now need to open every image
* file to find out its type.

  First, I distinguish between "real" objects and "emulated" objects; for
  example, an image file is a "real" file, whereas the root directory that
  it represents is an "emulated" directory.

  The following interpretations are supported:

    A real file can be treated as an emulated directory:
       - The file's filetype identifies the IFS which is to be used to effect
          this emulation
       - The file's doc_file_type* provides the filetype of the emulated
          directory

    A real file can represent an emulated file:
       - The file's filetype identifies the module which is used to effect
          this emulation
       - The file's doc_file_type* provides the filetype of the emulated file

    A real or emulated directory can be treated as an emulated file:
       - The directory's filetype* provides the filetype of the emulated file

     * These types must identify a document filetype (as opposed to a value
        which identifies an IFS or file emulation module).

  Other attributes of the real object apply equally to the emulated object;
  for example, if an image file has public read access, then so does the
  emulated directory.

  Limitations of this solution are:

    - File emulations cannot be nested (ie no encrypted compressed files for
       free)

    - An IFS implementation cannot be based on an emulated file that is
       actually a real directory ...


Symbolic links:
  A "symbolic link" can be thought of as replacing one file by another file
  or by another directory - so the techniques above could be used to achieve
  this effect. For example, symbolic links to other directories could be
  implemented as an IFS.

  In some ways, this seems like a sledge-hammer to crack a nut. A simpler
  approach is to build the concept in to FileSwitch along the following
  lines:

    - a new object type [4] - "symbolic link"
    - the new text is held in the directory entry

  Again, we have the problem of what attributes are read when - does
  read_info("$.fred") return the attributes for the file to which fred
  symbolically links, or of fred itself? How do you read the attributes of
  the other one?

  A user interface for creating, displaying and maintaining symbolic links
  also needs to be designed (icon with red-arrow?).

  Is there a worthwhile use for a symbolic link from one file to another
  *file*? If we restrict symbolic links to be to directories, the attribute
  problem becomes precisely the same as that for IFS. The remaining question
  is whether it is worth providing a special interface and implementation
  for symbolic links. If we do, here's a proposal:

    - new object type
    - all directory queries return information about the *link*, not about
       the directory to which it links
    - attempts to open the link itself are faulted
    - new functions are added to:
          - create a link object
          - delete a link object
          - read the link field in a link object
          - write the link field in a link object
    - link objects have owners and access permissions just like file and
       directory objects
    - Filer presents link as directory icon with arrow; double-clicking on
       this opens the linked directory (just like an IFS)

* The idea of an extra filetype field doesn't work for symbolic links, since
*  the type of the linked object is precisely that - ie it's not a fixed
*  value.
*
* So we must draw one of the following conclusions:
*   - symbolic links must be treated specially
*   - we must implement the extra filetype as a value returned by the IFS,
*      and implement symbolic links as an IFS
*
* The first approach is straightforward, and can be made as efficient as we
*  wish; it's easy to implement, but it's not "upwards compatible" in any
*  sense.
*
* The second approach is like using a sledgehammer to crack a nut, but is
*  in some sense a "minimal change" option.


Mounts v. symbolic links:
  Differences include:
    - a mount is explicitly connected each time a user logs on - whereas a
       symbolic link is evaluated whenever necessary
    - it's possible to step back up a directory hierarchy from a mounted
       object back to the tree containing the mount - but this is not
       supported for symbolic links [but I don't think this is a problem for
       RISC OS, since FileSwitch always talks in terms of full path names]
    - you can carry symbolic links around with you (plug in your floppy disc
       with links to your favourite remote filesystems and go!) - but this
       is more complex for mounts

  I don't think we need mounts if we support symbolic links to directories.


* There's a general problem about filetypes.
* At present, a filetype may indicate a document type, or may indicate an IFS
*  type; and this is a "dynamic" relationship, since we can only tell that a
*  IFS type is indicated if the corresponding IFS module has been loaded and
*  has registered itself with FileSwitch.
*
* We could change this by adding a bit to say "This is an image file" - but
*  it's tricky to do this in an upwards compatible way. (We'd have to say
*  that a file is an image file if it has this bet sit, or if its type is one
*  of those registered as an IFS before the release of NewCore ...)


* Another possible solution considered at the second meeting was:
*
*  - "view as single object" bit
*  - doc_file_type field
*
* The doc_file_type field is set iff the "view as single object" bit is set,
*  and in this case the Filer will display and treat the directory or image
*  file as a single object of the given type.
*
* This is a neat extension to existing facilities, and works well - except
*  that the technique is not appropriate for symbolic links, where the type
*  is "dynamic".

* I guess my inclination is towards the solution outlined above plus explicit
*  support for symbolic links; I think John's inclination is towards the more
*  general solution outlined in newattrs2.
