Hello,

has anyone an idea how to work with filespaces under Unix? Consider the
following problem as an example (it is a real problem from one of our
customers, not a constructed one, and it took us quite some time to
analyze, although we found no solution):

The customer writes:

  When I do a 'dsmc query archive -subdir "./*"' I see a different and
  disjoint set of files from a 'dsmc query archive -subdir "$HOME/*"'
  although my home directory is the current working directory.

The reason we found out is that ADSM stores files according to their paths
that may contain symbolic links. The shell (and different shells or the
same shell on different Unices may disagree) seems to resolve symbolic
links in the "." but not so symbolic links in "$HOME" or vice versa.
Hence, files stored as "./something" are found under "./*" and files
stored under "$HOME/something" are found under "$HOME/*" but in both cases
not vice versa. One half of the files of this user is stored with names
"/afs/lrz-muenchen.de/home/u/u123456/..." in the file space mounted at
"/afs/lrz-muenchen.de/home/u", the other half is stored under names
"/afs/lrz/home/u/u123456/..." and thus not in this file space.  "/afs/lrz"
is a symbolic link to "/afs/lrz-muenchen.de". This is *not* a problem of
AFS (which is only marginally supported under ADSM anyway) but the same
problem can occur under ordinary Unix file systems as well: there, too,
symbolic links in paths of home directories are frequently used to
encapsulate names of physical devices that have no bearing for the end
user.

There is no obvious solution:

Not defining vitual mount points underneath /afs would mean that the
  entirety of all AFS cells worldwide would form a single file space.

Dropping the symbolic link would render thousands of file paths wrong.

There is no way to force, persuade, or teach users to consistently use
  one version of the file path or the other: all other applications except
  ADSM know how symbolic links work and act consistently. This is an
  ADSM-only problem.

The only solution we have so far seen would be to write our own version
  of "dsmc query" which spawns as many "dsmc" processes as there are file
  spaces (now 35) and then combines the results. But this is a waste of both
  human and computer resources.

Writing a PMR or DCE to fix this bug is, according to all our
  experience, waste of time and effort: it is nowhere explicitly promised
  that this bug does not exist, so everything is "working as designed", even
  if ill-designed.

If other customers have run into the same problem and found solutions, we
would very much appreciate their assistance.

Also, we would appreciate if IBM could document how file spaces are defined:

by the virtual mountpoints currently defined at the requesting client

by the virtual mointpoints defined at the archiving client at the time
  of archive

by the union of the sets of virtual mountpoints ever defined at any client

by a combination of the above (e.g. file space is determined the third
  way but not changed if new mount points emerge after storage).

Best regards,

Helmut Richter

==============================================================
Dr. Helmut Richter                       Leibniz-Rechenzentrum
Tel:   +49-89-289-28785                  Barer Str. 21
Fax:   +49-89-2809460                    D-80333 Muenchen
Email: Helmut.Richter AT lrz-muenchen DOT de    Germany
==============================================================