Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Generic Filename Resolver

IP.com Disclosure Number: IPCOM000116470D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 126K

Publishing Venue

IBM

Related People

Weiss, B: AUTHOR

Abstract

Disclosed is a mechanism which enables a user to access files stored on his computer or on servers within a Local Area Network (LAN) by logical (alias) names without having to know their physical names and location. The term server is used here to identify a physical computer in a LAN containing files to be accessed. The physical name and location of a file can be changed without having to inform all users who access the file. This also includes moving files from one server to another within the LAN.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Generic Filename Resolver

      Disclosed is a mechanism which enables a user to access files
stored on his computer or on servers within a Local Area Network
(LAN) by logical (alias) names without having to know their physical
names and location.  The term server is used here to identify a
physical computer in a LAN containing files to be accessed.  The
physical name and location of a file can be changed without having to
inform all users who access the file.  This also includes moving
files from one server to another within the LAN.

      The Generic Filename Resolver (GFR) uses a table driven
mechanism.  It allows, by requiring only one drive letter, access to
an infinite number of physical files stored on any number of servers
in a LAN via symbolic filenames.  A customer may still access files
via their physical filename.  The symbolic filenames are resolved via
a GFR provided File System Driver (FSD) component.  It is assigned to
the driver letter used by the GFR.  The FSD gets control whenever a
file with the assigned drive letter is referenced via a standard
DosXxx() call.  If the filename resolving concept becomes part of the
operating system, the GFR provided FSD would not be required.

      As a result, files are "addressed" by logical customer provided
names defined in GFR tables, rather than via their fully qualified
physical name (composed of Drive:\Path\Filename).  The tables are
stored in plain ASCII text files on disk.  An administrator on the
customer's side may edit the tables via a standard text editor and
call the GFR provided table load function afterwards in order to get
the table entries verified and activated.  During this process, GFR
may still be active and running.

      The assignment of "aliases" for the various files is done in
one table, called System Navigation Table.  Introducing this table
suffices to eliminate the drive letter constraint.  The table mostly
contains navigation information necessary to uniquely identify a file
within a LAN.

      Another table, called System Configuration Table (SCT), is used
in order to allow a customer to create multiple SNT tables and to
assign them dynamically to a particular drive letter.  To avoid
ambiguity, SNTs are mutually exclusive assigned to drive letters.
The SCT table contains "aliases" which identify the physical
filenames of the SNT tables.

      In order to allow GFR finding the SCT, an environment variable,
say 'GFRSCT', is used.  It must be set to the full path and name of
the SCT.  As a consequence, a SNT table is attached via its alias
name in the SCT to a drive letter, rather than by its physical
filename.  This allows to "move" the SCT table to other local disks
with virtually zero administration impact; only the environment
variable has to be modified.  A SNT table may also change its name
and physical location, the only impact to GFR is to modify its entry
in the SCT.

      To allow files to be move...