
                                      Files
                                   30-Apr-2008 

  The original concept I had for New World OS was that the system wouldn't
  store data in files.  It would store data in a form which can be accessed
  directly by the computer.  I think it makes programs more complicated when
  they to convert a file into data they can read every time the program starts
  up and then have to convert it back to a file for output.

  If one needs the data in a file form to allow the data to be accessed by a
  different operating system, it would export the data into a file.  

  However, I did not have the time to write import and export functions for
  every kind of file that I needed to store, so I decided to just import files
  into the system uninterpreted until I could get it all working.

  I also wanted to eliminate file names in NWOS, however, until it was all
  working I had to keep the file names too, so I had a handle to access the
  files.  However, the same file could have different names and the same name
  could point to different files.  It is a many to many relationship.  So the
  way Objectify currently stores files and paths to the files is with three
  different classes.  A "FILE" object contains data pertaining to the file
  data.  A "FILE PATH" object contains the name or path name of the file.  And
  a "PATH AND FILE ASSOCIATION" links the two together.

  Another concept I had for New World OS was that it kept revisions of data.
  If you had a photo stored in NWOS and edited it with the GIMP, it would save
  the original photo and add a new revision, indicating what changes were made.

  I tried to keep that concept with the files stored in the system.  Both the
  import_file and disc_list programs have a --add-revision option that tells
  the system to add links between an old file and a new file of the same name.

  In the original concept (where there were no file names/paths) it was correct
  to just keep the versions of the data.  However, I discovered in version
  Alpha_27.1 that is broken when you mix in the many to many relationship of
  files and paths.

  For example if you have two files A and B and they are stored on a DVD and
  create a disc_list for that DVD.  Then you create a new revision of B so that
  it is now identical to A and store them both on a new DVD and create a new
  disc_list using --add-revision.  This causes an assert in Version_27.1 and
  prior versions (see bug #1954154).  It occurs because the new revision of B
  makes the data for file A a new revision of the old file B.  Yet file A was
  not revised.

  To make this all work correctly I have to change the system so that it is the
  PATH AND FILE ASSOCIATION objects that carry the revision information.  The
  bad news is that I cannot think of any way to make this change transparent. 
