[375] in arla-drinkers
Re: Infinite Recursion
daemon@ATHENA.MIT.EDU (Jon S. Stumpf)
Mon Nov 2 23:33:01 1998
From owner-arla-drinkers@stacken.kth.se Tue Nov 03 04:32:59 1998
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 3150 invoked from network); 3 Nov 1998 04:32:59 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 3 Nov 1998 04:32:59 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id FAA28469
for arla-drinkers-list; Tue, 3 Nov 1998 05:27:32 +0100 (MET)
Received: from mail.eclipse.net (root@mail.eclipse.net [207.207.192.13])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id FAA28464;
Tue, 3 Nov 1998 05:27:27 +0100 (MET)
Received: from mail.eclipse.net (wh2-148.eclipse.net [207.207.197.148])
by mail.eclipse.net (8.9.1a/8.9.1) with ESMTP id XAA26064;
Mon, 2 Nov 1998 23:27:18 -0500 (EST)
Message-ID: <363E8608.F50D6350@mail.eclipse.net>
Date: Mon, 02 Nov 1998 23:26:48 -0500
From: "Jon S. Stumpf" <jss@eclipse.net>
Reply-To: "Jon S. Stumpf" <jon.stumpf@acm.org>
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: Magnus Ahltorp <map@stacken.kth.se>
CC: ceez@bga.com, "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>,
Geoffrey Alan Washburn <gw2@andrew.cmu.edu>,
arla-drinkers@stacken.kth.se
Subject: Re: Infinite Recursion
References: <199811030207.VAA00275@hilfy.ece.cmu.edu>
<lv1btmpijg4.fsf@sundance.stacken.kth.se>
<199811030308.VAA01986@jake.bga.com> <lv17lxdihsv.fsf@sundance.stacken.kth.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
Magnus Ahltorp wrote:
> > Actually, I'm wondering what DFS did in this case? (Don't have
> > access to a system anymore). But, I think it behaved correctly.
I doubt it behaved correctly. AFS and DFS are represented by a single device
number in the UNIX filesystem table. Volume/fileset mount points must be tested
using the AFS/DFS system call extensions via pioctl, I believe. (It has been a
while since I touched this.)
Looking at ftp://ftp.transarc.com/pub/afs-contrib/tools/gnu-du/du.c, there is a
function that uses pioctl() to make the necessary test.
#ifdef AFS
int
is_AFS_mtpt (ent, follow_symbolic_links)
char *ent;
int follow_symbolic_links;
{
/* Space into which the mount point contents will be written.
* The format is "#|% [<cellname> :] <volname> . \0"
*/
char space[1+MAXCELLCHARS+1+VOLSER_OLDMAXVOLNAME+1+1];
struct ViceIoctl blob;
register long code;
blob.in = ent;
blob.in_size = strlen(ent) + 1;
blob.out = space;
blob.out_size = sizeof(space);
code = pioctl("./", VIOC_AFS_STAT_MT_PT, &blob,
follow_symbolic_links);
if (code)
if (errno == EINVAL)
return 0; /* Not a mount point */
else
error (errno, errno, "AFS pioctl failed");
else
return 1; /* Is a mount point */
}
#endif /* AFS */
The pioctl() command is VIOC_AFS_STAT_MT_PT. This procedure is similar in DFS
but I don't have time to find an example. I would suggest looking at some of
the work of Paul Henson for an example,
http://www.intranet.csupomona.edu/~henson/www/projects/ as I suspect some of his
excellent DFS tools (e.g., DFS-Perl) would perform a test such as this.
> I agree. It would be nice (volume boundaries are the way to go), I
> have no idea on how they have implemented this. It's possible to
> change device numbers at each volume boundary, but I don't know if
> that is a good solution (sounds like a hairy thing to do, besides,
> linux support would break).
>
> Ideas are welcome.
I don't believe changing device numbers is necessarily the right way to go.
An idea is to formally set a flag in the stat structure that indicates if this
entry is a mountpoint and require the stat() call to provide this information.
An application would check this bit for true to determine if this directory was
a mountpoint. POSIX would be updated and each VFS-specific stat() call would
have to be modifed to provide this information correctly. Essentially, I am
trying to propose a "standard" method of testing for a mountpoint rather than
relying on a change in st_dev to indicate it. This suggestion would still force
application changes initially but would permit a "standard" way of passing this
special information up through standard calls. The test should come out of the
stat() call, in my opinion.
Since this idea won't happen in a timeframe one would find practical, we have to
change the utilities.
Assuming that arla is targeting the FreeOS market, many of the GNU utilities
already include patches (and/or #ifdef conditionals) to become AFS-aware. For
those utilities that are not currently aware, fix them once in the standard
distribution and answer "yes" to an autoconf question "Are you using AFS?".
- jss
