GNU bug report logs - #33303
hex id for file system is incorrect or non-standard using uil 'id'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33303 in the body.
You can then email your comments to 33303 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Coreutils <bug-coreutils <at> gnu.org>
Subject: hex id for file system is incorrect or non-standard using uil 'id'
Date: Wed, 07 Nov 2018 08:07:50 -0800

Was looking to see when the underlying filesystem
changed in a path.

I used:
>  stat -f -c%f /
82100000000
stat -f -c%i /var
82200000000

There are way too many zeros, not to mention being left justfied
with zeros.

What I might expect to see is more like this:
821
or
822

mountpoint -d shows the maj:min for the given path (in decimal):
>  mountpoint -d /
8:33
>  mountpoint -d /tmp
8:34

Message #12 received at 33303-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: L A Walsh <coreutils <at> tlinx.org>, 33303-done <at> debbugs.gnu.org
Subject: Re: bug#33303: hex id for file system is incorrect or non-standard
 using uil 'id'
Date: Wed, 7 Nov 2018 17:58:39 +0100

tag 33303 notabug
close 33303
thanks

On 11/7/18 5:07 PM, L A Walsh wrote:
> Was looking to see when the underlying filesystem
> changed in a path.
> 
> I used:
>>  stat -f -c%f /
> 82100000000
> stat -f -c%i /var
> 82200000000
> 
> There are way too many zeros, not to mention being left justfied
> with zeros.
> 
> What I might expect to see is more like this:
> 821
> or
> 822

I think you didn't notice that -f changes the functionality of the "%f" format.

From 'stat --help':

   -f, --file-system     display file system status instead of file status

   ...
   Valid format sequences for file systems:
   ...
      %f     free blocks in file system

You can see with strace that the printed value comes from 'f_bfree':

  $ strace -ve statfs stat -f -c '%f' /
  ...
  statfs("/", {..., f_bfree=1561242, ...}, ...) = 0
  1561242
  +++ exited with 0 +++

As such, I'm marking this as "not a bug" in our bug tracker.
Of course, discussion may continue, and we can re-open the issue if needed.

Have a nice day,
Berny

Message #15 received at 33303-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: L A Walsh <coreutils <at> tlinx.org>, 33303-done <at> debbugs.gnu.org
Subject: Re: bug#33303: hex id for file system is incorrect or non-standard
 using uil 'id'
Date: Wed, 7 Nov 2018 20:22:13 +0100

On 11/7/18 5:58 PM, Bernhard Voelker wrote:
> tag 33303 notabug
> close 33303
> thanks
> 
> On 11/7/18 5:07 PM, L A Walsh wrote:
>> Was looking to see when the underlying filesystem
>> changed in a path.
>>
>> I used:
>>>  stat -f -c%f /
>> 82100000000
>> stat -f -c%i /var
>> 82200000000

sorry, I overlooked the %i example:

%i comes from the f_sid member of the returned structure from statfs(),
just printed in hex format:

  statfs("/", {..., f_fsid={val=[3357913161, 1752493561]}, ...}) = 0
  ...
  write(1, "c825b0496874edf9\n", 17)      = 17
  c825b0496874edf9
  close(1)                                = 0
  close(2)                                = 0
  exit_group(0)                           = ?
  +++ exited with 0 +++

  $ printf '%x' 3357913161 1752493561
  c825b0496874edf9

So it seems to be a quite some strange incident that your f_bfree value
is so eye-catchingly close to f_fsid.

Have a nice day,
Berny

Message #18 received at 33303-done <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 33303-done <at> debbugs.gnu.org
Subject: Re: bug#33303: hex id for file system is incorrect or non-standard
 using uil 'id'
Date: Thu, 08 Nov 2018 02:53:46 -0800

On 11/7/2018 11:22 AM, Bernhard Voelker wrote:
>> On 11/7/18 5:07 PM, L A Walsh wrote:
>>> Was looking to see when the underlying filesystem
>>> changed in a path.
>>>
>>> I used:
>>>>  stat -f -c%f /
>>> 82100000000
>>> stat -f -c%i /var
>>> 82200000000
> 
> sorry, I overlooked the %i example:
---
	Both should be %i for the file system ID in hex.
How is it that the fs ID is the same as the device
number of the file system?

i.e.
8:34 =  8:21 in hex
8:33 =  8:22 in hex

Message #21 received at 33303-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 33303-done <at> debbugs.gnu.org
Subject: Re: bug#33303: hex id for file system is incorrect or non-standard
 using uil 'id'
Date: Thu, 8 Nov 2018 15:19:34 +0100

On 11/8/18 11:53 AM, L A Walsh wrote:
>     Both should be %i for the file system ID in hex.
> How is it that the fs ID is the same as the device
> number of the file system?
> 
> i.e.
> 8:34 =  8:21 in hex
> 8:33 =  8:22 in hex

dunno - I assume this is the secret of the implementation of the file system.
Did you verify with strace?  I'm quite sure 'stat' only forwards the
values from the system call.

Have a nice day,
Berny

Message #24 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: prob no. thirty-three thousand, three-hundred & three: hex id
 for file system is incorrect
Date: Thu, 29 Nov 2018 02:05:53 -0800

The reason I was confused about the output -- is that
it really is messed up. (3-3-3-0-3)

On 11/8/2018 6:19 AM, Bernhard Voelker wrote:
> On 11/8/18 11:53 AM, L A Walsh wrote:
>>     Both should be %i for the file system ID in hex.
>> How is it that the fs ID is the same as the device
>> number of the file system?
>>
>> i.e.
>> 8:34 =  8:21 in hex
>> 8:33 =  8:22 in hex
> 
> dunno - I assume this is the secret of the implementation of the file system.
> Did you verify with strace?  I'm quite sure 'stat' only forwards the
> values from the system call.
----

Nope.  It's just wrong: someone added a define, above, 
around #116:

#  define f_fsid dev

So instead of a fsid, it's the device number in hex
with an extra 8 0's tacked on the end.

Does your source control allow finding out when that was added
and by whom?

tnx...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.