Re: coreutils-6.9 and Tru64 UNIX 5.1 FFM mounts

[Albert Chin]

On Fri, Jul 06, 2007 at 06:37:24PM +0200, Jim Meyering wrote:
> Albert Chin <address@hidden> wrote:
> 
> > On Fri, Jul 06, 2007 at 08:33:17AM +0100, James Youngman wrote:
> >> On 7/6/07, Albert Chin <address@hidden> wrote:
> >> >Using GNU df from coreutils-5.9:
> >> ># gdf -k /mnt/foo
> >> >gdf: `/mnt/foo': Invalid argument
> >> >gdf: no file systems processed
> >>
> >> Perhaps you could provide an extract from a system call trace
> >> indicating which system calls returned EINVAL, and on what.
> >
> > The following is the output from running truss against GNU df:
> >   $ /usr/opt/svr4/bin/truss -f -o /tmp/a ./df /mnt/foo
> > 116927: stat("/mnt/foo", 0x0000000140006800)            = 0
> > 116927: getfsstat(0x00000000, 0, MNT_NOWAIT)            = 10
> > 116927: getfsstat(0x0000000140008000, 28160, MNT_NOWAIT) = 10
> > 116927: statfs("/mnt/foo", 0x000000011FFFAEA0, 4831820176) = 0
> > 116927: pathconf(0x000000011FFFB0A0, 14)                Err#22 Invalid 
> > argument
> 
> Thanks for investigating.
> I see no direct use of pathconf by df.c or the functions it usually calls,
> so it must be called via some portability framework or library call.
> 
> Is PATH_MAX defined on that system?

Yes, in <sys/syslimits.h>:
  #define PATH_MAX        1023    /* max number of bytes in pathname */

> I.e., I'm beginning to suspect that the pathconf use is via
> canonicalize.c's use of PATH_MAX, which may be defined to
> pathconf("/", _PC_PATH_MAX).  In that case, is _PC_PATH_MAX
> defined on your system?

We tracked down the error to lib/fsusage.c. statvfs() is returning
EINVAL in get_fs_usage(). STAT_STATVFS is defined on this platform so
the code path is:
  int
  get_fs_usage (char const *file, char const *disk, struct fs_usage *fsp)
  {
  #if defined STAT_STATVFS                /* POSIX */

    struct statvfs fsd;

    if (statvfs (file, &fsd) < 0)
      return -1;

The Tru64 UNIX df(1) uses statfs(). I modified config.h so
STAT_STATVFS is undefined and STAT_STATFS3_OSF1 is defined:
  $ ./df -k /mnt/foo
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/zero              6290784   2327550   3925384  38% /mnt/foo

The system df(1) gives a similar result:
  $ df -k /mnt/foo
  Filesystem  1024-blocks        Used   Available Capacity  Mounted on
  /dev/zero       6290784     2327550     3925384    38%    /mnt/foo

So, looks like we don't want STAT_STATVFS on this platform. Maybe we
should check for STAT_STATFS3_OSF1 first in m4/fsusage.m4 before
STAT_STATVFS?

-- 
albert chin (address@hidden)