bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils-6.9 and Tru64 UNIX 5.1 FFM mounts


From: Jim Meyering
Subject: Re: coreutils-6.9 and Tru64 UNIX 5.1 FFM mounts
Date: Fri, 06 Jul 2007 18:37:24 +0200

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?
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?

Probably the easiest way to check all this is
to use a debugger to set a break point at pathconf
and then print a stack trace once it gets there.
Can you do that?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]