On 03/11/2013 08:39 PM, Tyler Hobbs wrote: > If I run stat --printf='%D', the result is "10ca70", which is correct. > However, if I run stat --printf='%t %T' /mountpoint, the result is > erroneously "0 0". If I instead run stat against the device directly (stat > --printf='%t %T' /dev/xvdx), I get the correct result of "ca 170". > > I believe the proper fix is to replace (in stat.c): > > out_uint_x (pformat, prefix_len, major (statbuf->st_rdev)); > > with: > > out_uint_x (pformat, prefix_len, major (statbuf->st_dev)); > > That is, use statbuf->st_dev instead of st_rdev, which is what the %d and > %D directives use. > > > I'm using coreutils 8.9, compiled from source, and this is the output of > uname -a: > > Linux ip-10-39-122-238 2.6.32-276.el6.x86_64 #1 SMP Tue May 29 17:38:19 EDT > 2012 x86_64 x86_64 x86_64 GNU/Linux > > Thanks for your time. > - Tyler > So %t and %T are only currently defined for device special files, allowing one to distinguish between the represented device and the device of the inode storing the representation (the special file). $ stat -c '%T%t %D' /dev/sda /dev 08 5 00 5 Now %t and %T returning 0 for non special device nodes is not that useful. I suppose in this case we might use st_rdev only for block and char specials, and switch to st_dev otherwise. However... st_rdev is not always 0 I notice that st_rdev is not 0 on FreeBSD 9 for files. I don't know what it represents, but it's non random so may be significant. Also the man page I have here says that on XENIX named special file subtypes are distinguished by st_rdev values Also is it useful to get low level access like this to the backing device major and minor for normal files from a shell script? So I think we'll just improve this through documentation. Hopefully the attached clarifies things. thanks, Pádraig.
stat-rdev.patch
Description: Text Data
--- End Message ---