Proposed AFS '-type afsvmount' switch

[Steve Simmons]

I'm going to be hacking on findutils a bit to restore and extend some
of the AFS-specific features, and to provide regular AFS-based testing
for findutils.  First on the list is fixing the configuration scripts
so AFS is properly detected and the appropriate -I/-L/-l switches
generated; and then a switch to detect afs volume mount points.

Some general background on where AFS is an uncomfortable fit for find
is appropriate here.  AFS permits or promotes a number of actions which
are pretty foreign or non-existant in UNIX file systems:

   o  Unprivileged users can attach and detatch volumes at will
      This means users can and do create circular mount trees.
      Thus find may have to deal with issues in AFS trees that
      don't occur in UNIX file system, and one cannot depend on
      the sysadmin to have done the rational thing.

   o  A volume need not exist to be mounted.  A user can mount
      an arbitrary volume name onto a directory, and the mount
      point is created.  Errors occur when you try to traverse
      it, and must be handled in some rational way.  One useful
      find function would be to find all non-existant volume
      mounts in a tree.

   o  Backup copies of user volumes may exist.  These may or
      may not differ from the user volume in any signficant
      way, and typically one would like to somehow exclude backup
      volumes from a search either at time of creation of the
      db or when using the locate or find commands interactively.

   o  Volumes have names, and names have meanings.  One may wish
      to include or exclude a class of volumes based on the name
      (or a regexp, I suppose).  Backup volume names end in
      .backup, as a simple example.  But it might also be useful
      to find only files which exist in 'user.*' volumes, or
      in some departments tree.

   o  Pruning trees at volume mount points can prevent recursion.

   o  AFS volumes can be mounted from multiple cells, where a cell
      is roughly a collection of servers that forms a unified
      administrative namespace.  Ability to restrict actions to
      specific cells is a plus.  Especially because AFSs root-like
      permissions do not typically cross cell boundaries.  :-)

   o  Ability to detect cell boundaries can prevent massive
      problems with network timouts, particularly if someone
      naively attempts to index /afs.

In short, proper AFS support in find is a non-trivial task.  Many
of the things find does simply don't make sense in an AFS environment,
and find should do something intelligent when facing such issues.

As best I can tell, AFS support in find has been minimal but acceptable
within its limits.  My goal is to expand those limits slightly, but
not to attempt to make find into something it isn't.

One of the first things on my list is the ability to have find recognise
an AFS volume mount point and be able to do the normal stuff with it;
eg, print the name, prune the tree, etc.

My rationale is as follows:

We want to prevent circular usage (recursive mounts), and restricting
a search to only a given volume is possible if find can recognise
a volume mount point and do the following:

   find . \( -fstype afsvmount -prune \) -o -print

This relatively simple change should get my feet wet with autoconf and
the find code, and will lead to other features.  High runners on my list
include a -afsvname switch that would let one detect volumes by name
much like -name does, and an -afscname switch that would do the same
for cell names.  Beyond that I'd like to do something with ACL detection
and use, eg, finding files that have no AFS/pts owner or where ACL entries
contain references to non-existant accounts; and adding %items to printf
formats that would let you easily generate information about found files.
But that's quite a bit further down the road.  First ./configure, then
-fstype afsvmount.

Steve
-- 
"In my darker moments I consider creating the eeyore fan club with a theme
song by Leonard Cohen, logo by Edvard Munch and costumes by Tim Burton."
   -- anonymous, forwarded by Ellen.