Enhanced File Stats Being Worked On For The Linux Kernel

[phoronix]

Phoronix: Enhanced File Stats Being Worked On For The Linux Kernel

Red Hat has been working on a new statx system call for the Linux kernel to provide "enhanced" file information...

http://www.phoronix.com/scan.php?page=news_item&px=Enhanced-File-Stats-statx-Linux

[bachchain]

Neat.

[fld-]

Oh sweeeeet! Maybe in 2017 we will finally get the ability to sort files based on their Birth Date in file managers such as Dolphin.
Didn't really have my hopes up after I first found out about why this isn't currently possible in linux: https://lkml.org/lkml/2010/7/22/249
It's been long enough!

[Danny3]

Most of the time the only timestamp I'm interested in looking on a file's properties is the creation time and Linux shows everything except that.
Another thing that Windows had from version 1 and Linux doesn't show it after all these years.
This is just another thing that keeps me from switching to Linux on my home computers.

[pal666]

Most of the time the only timestamp I'm interested in looking on a file's properties is the creation time and Linux shows everything except that.
Another thing that Windows had from version 1 and Linux doesn't show it after all these years.
This is just another thing that keeps me from switching to Linux on my home computers.

lol. windows version 1 was gui shell for dos and dos version 1 had no directories and no file descriptors
btw, looks like you got bribed and accepted microsoft on you home computers lol

[tocretpa]

Awesome

[FishPls]

It's honestly so frustrating that i can't see my file creation date's on ext4. It just seems utterly stupid.

[timofonic]

(1) Better support for the y2038 problem [Arnd Bergmann].

Aka "Unix Millennium Bug".

Despite there's too much time until 2038 (2038-2016=), I'm surprised this isn't solved earlier. It seems NetBSD and OpenBSD solved it earlier.

What about replacing UNIX time with ISO 8601? UTR1? UT2?

There's another time related bug in NTP itself, but it's about 2036 instead.

(2) Creation time: The SMB protocol carries the creation time, which could
be exported by Samba, which will in turn help CIFS make use of
FS-Cache as that can be used for coherency data.

This is also specified in NFSv4 as a recommended attribute and could
be exported by NFSD [Steve French].

Is it used by default? What about old implementations?

(3) Lightweight stat: Ask for just those details of interest, and allow a
netfs (such as NFS) to approximate anything not of interest, possibly
without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
Dilger].

WTF? Interest to what?

(4) Heavyweight stat: Force a netfs to go to the server, even if it thinks
its cached attributes are up to date [Trond Myklebust].

What?

(5) Data version number: Could be used by userspace NFS servers [Aneesh
Kumar].

Can also be used to modify fill_post_wcc() in NFSD which retrieves
i_version directly, but has just called vfs_getattr(). It could get
it from the kstat struct if it used vfs_xgetattr() instead.
[/quote]

Okay. What's this useful about too?

(6) BSD stat compatibility: Including more fields from the BSD stat such
as creation time (st_btime) and inode generation number (st_gen)
[Jeremy Allison, Bernd Schubert].

Seriously: Why this hasn't been standarized with them instead? Why both BSD and Linux at least do the same stuff in this? Is it so difficult?

(7) Inode generation number: Useful for FUSE and userspace NFS servers
[Bernd Schubert]. This was asked for but later deemed unnecessary
with the open-by-handle capability available

So no interest or what? I would like FUSE and others would be faster...

(8) Extra coherency data may be useful in making backups [Andreas Dilger].

What this?

(9) Allow the filesystem to indicate what it can/cannot provide: A
filesystem can now say it doesn't support a standard stat feature if
that isn't available, so if, for instance, inode numbers or UIDs don't
exist or are fabricated locally...

What??

(10) Make the fields a consistent size on all arches and make them large.

How?

(11) Store a 16-byte volume ID in the superblock that can be returned in
struct xstat [Steve French].

What's is this useful for? 16bit?

(12) Include granularity fields in the time data to indicate the
granularity of each of the times (NFSv4 time_delta) [Steve French].

Recursivity of recursivity? WTF?

(13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.
Note that the Linux IOC flags are a mess and filesystems such as Ext4
define flags that aren't in linux/fs.h, so translation in the kernel
may be a necessity (or, possibly, we provide the filesystem type too).

So why that happened? How can get fixed? Why BSD follows different stuff? What about standarize it with BSD and others if possible?

(14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
Michael Kerrisk].

What? Mask?

(15) Spare space, request flags and information flags are provided for
future expansion.

What?

Note that not all of the above are implemented here.

OKay...


Are there a consensus between BSD derivatives and other operating systems now?

From Linus Torvalds <>
Date Thu, 22 Jul 2010 08:14:42 -0700
Subject Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]


On Thu, Jul 22, 2010 at 5:17 AM, Volker Lendecke
<[email protected]> wrote:
> On Thu, Jul 22, 2010 at 01:14:47PM +0100, David Howells wrote:
>> Jan Engelhardt <[email protected]> wrote:
>>
>> > Linux already has a creation time field, it's called otime (there is no "b"
>> > in "creation"), and you will find scattered fragments of that all over the
>> > kernel (foremost, fs/jfs/, now btrfs, and I also notice sysvipc having
>> > something with that name).
>>
>> It is? It's called crtime in Ext4. st_btime, however, would be compatible
>> with BSD's stat, and Samba would just use it by way of autoconf magic if it
>> appeared.
>
> Samba has the following check:
>
> # recent FreeBSD, NetBSD have creation timestamps called birthtime:
> AC_CHECK_MEMBERS([struct stat.st_birthtimespec.tv_nsec])
> AC_CHECK_MEMBERS([struct stat.st_birthtime], AC_CHECK_MEMBERS([struct stat.st_birthtimensec]))
>
> and the supporting code around that. "birth" might also be
> where the "b" comes from :-)

Oh wow. And all of this just convinces me that we should _not_ do any
of this, since clearly it's all totally useless and people can't even
agree on a name.

Let's wait five years and see if there is actually any consensus on it
being needed and used at all, rather than rush into something just
because "we can".

[Danny3]

lol. windows version 1 was gui shell for dos and dos version 1 had no directories and no file descriptors
btw, looks like you got bribed and accepted microsoft on you home computers lol

Lol, I didn't mean it literally, I wanted to say that Microsoft got it right from the beginning.
It baffles me that after two decades Linux still cannot record or display such a simple thing.
Nice joke, but I think the majority of us started with Windows and seen that there are a lot well thought things (up to Windows 7), like the display of creation time, which btw, is the first timestamp displayed on file properties. I looks like they understand it's importance.

[pal666]

Lol, I didn't mean it literally, I wanted to say that Microsoft got it right from the beginning.

in reality microsoft got it wrong from the beginning and moved towards unix with every release

It baffles me that after two decades Linux still cannot record or display such a simple thing.

because nobody needs it. there is no meaningful difference between creation time and modification time because often used way of modifying file is to create new one and then rename

I think the majority of us started with Windows and seen that there are a lot well thought things (up to Windows 7), like the display of creation time, which btw, is the first timestamp displayed on file properties. I looks like they understand it's importance.

it looks like they have no inodes and you want to repeat broken windows behavior on linux