archie/prospero/doc/names.txt
2024-05-27 16:13:40 +02:00

278 lines
12 KiB
Plaintext

This is Mitra's understanding of Prospero's different naming schemes and
their interrelationship, based upon phone conversations with Steve.
I found
and still find these incredibly confusing, and this is a first cut at
a summary. I've neccessarily skipped over much of the details to avoid
confusing the reader. I'm using examples based upon our system which -
I believe - accepts all the sensible defaults. The system is flexible
enough that none of this could be correct, but in that case you'd probably
know enough not to be reading this.
There are three different naming schemes for files around Prospero.
A) The regular unix filename, this is rarely used in Prospero
B) User-level-names, which are relative to virtual file systems. Similarly to
unix filenames, if you specify these without leading /, then they are
relative to the current working directory. (see environment below)
user-level names are always relative to the virtual file system you
are set up in. This is the state set up by the "vfsetup" command.
C) Hsonames - Host Specific Object Names, always accompanied by a host(port)
to specify which host(port) it's meaningfull at. This concept is often
simplified to "hsoname". Except in the case of gateways, hsonames are
usually the real (unix) name of the file on the remote system.
Who uses what names
-------------------
Most of the data structures - vlink, vdirs etc use host(port) and hsoname (C).
Various functions map between them - especially rd_vlink will take a User-level
name (B), and return a vlink (host(port) and hsoname) (C)
Most commands - e.g. set_atr take User-level names (B)
vln -n is used to create a user-level name (B) for a hsoname (C)
Variations on User Level names
------------------------------
The way that a user-level name appears is significantly more complicated
than a standard unix filename. For what follows, lets assume you
are set up in the Virtual File System "aol", and that your system is setup
the way most are.
/ is the root of your virtual system
xxx/yyy is relative to the current workign directory (see vwd)
swa:/zzz means /zzz relative to the virtual file system "swa"
#/INET/EDU/ISI/swa means the swa virtual file system on isi.edu, this is
sometimes called a global-name, with # being the global root.
swa:zzz Has a currently undefined meeting DONT USE IT
In reality, these are all based upon certain links being
present in the user-level directory /VIRTUAL-SYSTEMS.
Expressed differently, your virtual system looks like this
/ Root of virtual system
/aol Typically your home directory.
/VIRTUAL-SYSTEMS/ Links to other virtual systems
/VIRTUAL-SYSTEMS/swa/ Link to swa's virtual system description (also
often stated as "link to swa's virtual system"). This
can also be expressed as swa:/VS-DESCRIPTION
/VIRUTAL-SYSTEMS/swa/ROOT Link to the root of swa's virtual system system. This
can also be expressed as swa:/
/VIRTUAL-SYSTEMS/#/ Link to global root aka "#/"
/VS-DESCRIPTION/ Definition of your virtual system
/VS-DESCRIPTION/ROOT/ Root of your virtual system same as "/"
/VS-DESCRIPTION/HOME/ Home directory, "cwd" at startup, same as /aol
To link a virtual system into this - use the command
vln #/INET/EDU/ISI/swa:/VS-DESCRIPTION /VIRTUAL-SYSTEMS/swa
Unix filesystem to virtual file system
--------------------------------------
hsoname's map to Unix names real easy - they are the same except for hsonames
that don't start with a slash. e.g.: GOPHER-GW/PATH.NET(8001)/1/
user-level names are more complicated, the root of the "aol" virtual file
system will (according to swa) typically be /usr/pfs/pfsdat/local-vsystems/aol
On our system, I find the following structure:
/usr/pfs Root of our prospero data area
/usr/pfs/pfsdat Real hierarchy of prospero data
/usr/pfs/pfsdat/vs Dont know what this is - there is NOTHING in it
/usr/pfs/shadow Start of shadow hierarcy, links and attributes
/usr/pfs/shadow/xyz Shadow hierarchy for Unix directory /xyz
/usr/pfs/shadow/usr/pfs/pfsdat Shadow of data area
/usr/pfs/shadow/usr/pfs/pfsdat/local_vsystems/aol root of aol virtual system
/usr/pfs/shadow/usr/pfs/pfsdat/local_vsystems/master virtual-systems directory
is master copy of all vs's at this site
/usr/pfs/shadow/usr/pfs/pfsdata/local_vsystems/master/storage specifies
hosts where virtual-systems on this site can be stored
/usr/pfs/shadow/usr/pfs/pfsdat/local_vsystems/protoype copied by newvs
/usr/pfs/shadow/usr/pfs/pfsdat/vs/ junk created by newpsite?
/usr/pfs/shadow/usr/pfs/pfsdat/vs:1 ditto
Each directory in the shadow typically contains a file
".directory#contents" with attribute information and links in it.
(This is soon to be supreseded by .directory#object)
Environment variables
---------------------
Certain environment variables give the base which maps user-level names to
hsonames and Unix names. vfsetup sets these up. The hsoname is always the
Unix name for the directory, but beware, this directory may only exist under
the shadow hierarchy.
VSWORK User-level name for cwd
VSWORK_HOST Host of cwd
VSWORK_FILE hsname of cwd
VSDESC_HOST and VSDESC_FILE host and hsoname of VSDESCRIPTION directory
this always has the user-level name of /VS-DESCRIPTION
VSHOME,VSHOME_HOST and VSHOME_FILE user-level, host and hsoname of
home directory.
VSROOT_HOST and VSROOT_FILE host and hsoname of Root directory
this always has the user-level name of /
(Note at some time the _FILE variables will probably be replaced with _HSONAME)
Other information:
------------------
See the manual 5.1 for more details (but absolutely ZERO examples)
vwp - will tell you the host and hsoname of the current working directory
vwd - will give the user-level name of the cwd.
Whats wrong with this!
----------------------
Having described it, here are some ideas on what is wrong with it.
*) Hsonames are long, and expose internal directory structure
to external view. Clients shoudlnt need to have to know where
my prospero directories are kept. Contrast gopher, where paths
are short and typically something like / or /Agriculture
*) Confusion of two names (hsoname and virtual name). And two
physical directory trees (real and shadow)
*) object-pool, picking another arbitrary location for directories
that appear only in the shadow hierarchy but not in the real hierarchy is
a bad move. Especially since many of these are going to aquire real
files at some point (e.g. About files).
*) Multiple steps for simple operations - e.g. needing vmkdir and mkdir
to create something, causes potential for mistakes.
*) vmv is not available, and really hard to do by hand, since
the things you are trying to move are in multiple locations.
This is Mitra's understanding of Prospero's different naming schemes and
their interrelationship, based upon phone conversations with Steve.
I found
and still find these incredibly confusing, and this is a first cut at
a summary. I've neccessarily skipped over much of the details to avoid
confusing the reader. I'm using examples based upon our system which -
I believe - accepts all the sensible defaults. The system is flexible
enough that none of this could be correct, but in that case you'd probably
know enough not to be reading this.
There are three different naming schemes for files around Prospero.
A) The regular unix filename, this is rarely used in Prospero
B) User-level-names, which are relative to virtual file systems. Similarly to
unix filenames, if you specify these without leading /, then they are
relative to the current working directory. (see environment below)
user-level names are always relative to the virtual file system you
are set up in. This is the state set up by the "vfsetup" command.
C) Hsonames - Host Specific Object Names, always accompanied by a host(port)
to specify which host(port) it's meaningfull at. This concept is often
simplified to "hsoname". Except in the case of gateways, hsonames are
usually the real (unix) name of the file on the remote system.
Who uses what names
-------------------
Most of the data structures - vlink, vdirs etc use host(port) and hsoname (C).
Various functions map between them - especially rd_vlink will take a User-level
name (B), and return a vlink (host(port) and hsoname) (C)
Most commands - e.g. set_atr take User-level names (B)
vln -n is used to create a user-level name (B) for a hsoname (C)
Variations on User Level names
------------------------------
The way that a user-level name appears is significantly more complicated
than a standard unix filename. For what follows, lets assume you
are set up in the Virtual File System "aol", and that your system is setup
the way most are.
/ is the root of your virtual system
xxx/yyy is relative to the current workign directory (see vwd)
swa:/zzz means /zzz relative to the virtual file system "swa"
#/INET/EDU/ISI/swa means the swa virtual file system on isi.edu, this is
sometimes called a global-name, with # being the global root.
swa:zzz Has a currently undefined meeting DONT USE IT
In reality, these are all based upon certain links being
present in the user-level directory /VIRTUAL-SYSTEMS.
Expressed differently, your virtual system looks like this
/ Root of virtual system
/aol Typically your home directory.
/VIRTUAL-SYSTEMS/ Links to other virtual systems
/VIRTUAL-SYSTEMS/swa/ Link to swa's virtual system description (also
often stated as "link to swa's virtual system"). This
can also be expressed as swa:/VS-DESCRIPTION
/VIRUTAL-SYSTEMS/swa/ROOT Link to the root of swa's virtual system system. This
can also be expressed as swa:/
/VIRTUAL-SYSTEMS/#/ Link to global root aka "#/"
/VS-DESCRIPTION/ Definition of your virtual system
/VS-DESCRIPTION/ROOT/ Root of your virtual system same as "/"
/VS-DESCRIPTION/HOME/ Home directory, "cwd" at startup, same as /aol
To link a virtual system into this - use the command
vln #/INET/EDU/ISI/swa:/VS-DESCRIPTION /VIRTUAL-SYSTEMS/swa
Unix filesystem to virtual file system
--------------------------------------
hsoname's map to Unix names real easy - they are the same except for hsonames
that don't start with a slash. e.g.: GOPHER-GW/PATH.NET(8001)/1/
user-level names are more complicated, the root of the "aol" virtual file
system will (according to swa) typically be /usr/pfs/pfsdat/local-vsystems/aol
On our system, I find the following structure:
/usr/pfs Root of our prospero data area
/usr/pfs/pfsdat Real hierarchy of prospero data
/usr/pfs/pfsdat/vs Dont know what this is - there is NOTHING in it
/usr/pfs/shadow Start of shadow hierarcy, links and attributes
/usr/pfs/shadow/xyz Shadow hierarchy for Unix directory /xyz
/usr/pfs/shadow/usr/pfs/pfsdat Shadow of data area
/usr/pfs/shadow/usr/pfs/pfsdat/local_vsystems/aol root of aol virtual system
/usr/pfs/shadow/usr/pfs/pfsdat/local_vsystems/master virtual-systems directory
is master copy of all vs's at this site
/usr/pfs/shadow/usr/pfs/pfsdata/local_vsystems/master/storage specifies
hosts where virtual-systems on this site can be stored
/usr/pfs/shadow/usr/pfs/pfsdat/local_vsystems/protoype copied by newvs
/usr/pfs/shadow/usr/pfs/pfsdat/vs/ junk created by newpsite?
/usr/pfs/shadow/usr/pfs/pfsdat/vs:1 ditto
Each directory in the shadow typically contains a file
".directory#contents" with attribute information and links in it.
(This is soon to be supreseded by .directory#object)
Environment variables
---------------------
Certain environment variables give the base which maps user-level names to
hsonames and Unix names. vfsetup sets these up. The hsoname is always the
Unix name for the directory, but beware, this directory may only exist under
the shadow hierarchy.
VSWORK User-level name for cwd
VSWORK_HOST Host of cwd
VSWORK_FILE hsname of cwd
VSDESC_HOST and VSDESC_FILE host and hsoname of VSDESCRIPTION directory
this always has the user-level name of /VS-DESCRIPTION
VSHOME,VSHOME_HOST and VSHOME_FILE user-level, host and hsoname of
home directory.
VSROOT_HOST and VSROOT_FILE host and hsoname of Root directory
this always has the user-level name of /
(Note at some time the _FILE variables will probably be replaced with _HSONAME)
Other information:
------------------
See the manual 5.1 for more details (but absolutely ZERO examples)
vwp - will tell you the host and hsoname of the current working directory
vwd - will give the user-level name of the cwd.