Linus on btime: “Let’s wait five years” (2010) | Hacker News Reader

Linus on btime: “Let’s wait five years” (2010)

lkml.iu.edu

73 pointswener40 comments

Maybe it's time ?

btime I mean

Under Linux

    $ stat `which stat`
      File: '/usr/bin/stat'
      Size: 80944           Blocks: 160        IO Block: 4096   regular file
    Device: fd01h/64769d    Inode: 1196257     Links: 1
    Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-09-22 15:30:03.759501920 +0800
    Modify: 2016-02-18 21:37:47.000000000 +0800
    Change: 2016-09-08 18:17:26.611169858 +0800
     Birth: -

Under OSX

    $ stat `which stat`
      File: '/usr/local/opt/coreutils/libexec/gnubin/stat' -> '../../bin/gstat'
      Size: 15             	Blocks: 8          IO Block: 4096   symbolic link
    Device: 1000004h/16777220d     	Inode: 17293277    Links: 1
    Access: (0755/lrwxr-xr-x)  Uid: (  501/   wener)   Gid: (   80/   admin)
    Access: 2016-01-26 19:01:40.000000000 +0800
    Modify: 2016-01-21 02:56:37.000000000 +0800
    Change: 2016-01-26 19:01:40.000000000 +0800
     Birth: 2016-01-21 02:56:37.000000000 +0800

So what is the difference between "modify" and "change"??

Content modification vs. metadata modification I believe.

It's the other way around. ctime (status change) for metadata, mtime (modification) for files contents, atime (access) for file access.

Part of the confusion for {c,m}time probably comes from

  [c]time: [c]hange       [m]etadata
  [m]time: [m]odify] file [c]ontents

yeah, that was my first reaction: how do I know which one is which?

well, if you need to check in future, like this:

    $ man 2 stat

ctime is when the inode or file changes in terms of stat, ownership, etc. mtime is when the contents of the file is changed.

Off Topic — Which one is better?

    $ stat `which stat`
    $ stat $(which stat)

Backticks if lazy, parenthetical for complicated command lines.

Haha, I read that as "...complicated command times."

Close enough!

Backticks are discouraged for any new scripts, since they complicate nesting, quoting, and escaping, besides being graphically less explicit. See also http://mywiki.wooledge.org/BashFAQ/082. The Open Group also discourages backticks: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_....

    $ stat "$(which stat)"

shellcheck or its online version http://www.shellcheck.net/ help a lot

$(...) doesn't trip Shellcheck and is slightly more readable and less error-prone in complex statements, e.g. if you have to nest commands.

which probably isn't the best tool to use here.

http://unix.stackexchange.com/questions/85249/why-not-use-wh...

I was about to ask how you got that pretty-print output from OSX's `stat` before I noticed you were using `gstat`. Oddly enough, the native `stat -x` gives a similar output but omits birth time:

    $ stat -x `which stat`
      File: "/usr/bin/stat"
      Size: 27376        FileType: Regular File
      Mode: (0755/-rwxr-xr-x)         Uid: (    0/    root)  Gid: (    0/   wheel)
    Device: 1,4   Inode: 192606219    Links: 1
    Access: Thu Sep 22 11:50:55 2016
    Modify: Fri Jul  8 23:03:34 2016
    Change: Sun Jul 31 21:44:22 2016

> 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".

This is why every project maintainer dreams of being Linus...

Well it IS pretty useful; that's why most of my documents start with a date part like "160822 Something Something"; they'll still be sorted by /creation time/ next time I make a change.

Also very useful for photographs for example, when you can edit the EXIF without the whole lot becoming randomly sorted.

Yeah, I use creation time all the time on OS X. Meanwhile I can't imagine what access time would be used for.

We use atime at work as a proxy for "does this file really need to exist?" on our cluster's scratch disks.

atime is heavily used by traditional mail clients like mutt, to determine which mailboxes have new mail: If atime < mtime, then there has been a write to a file since the last read.

Because updating atime on every file access carries an IO overhead, there's a mount option "relatime" that only updates atime if atime < mtime. This preserves the "new mail" feature of mutt, but doesn't require atime writes for every file read operation, which is a decent compromise.

relatime has also been the default on Linux for many years.

I've been wanting to write a program that checks atime on stuff like music and then looks for bitcoin addresses to send micropayments to (so you get something like a generalised peer to peer Spotify). I've started a couple times but kept throwing it out, all my FSs that support it are still mounted with atime. I guess I've never knowingly used it for anything else though.

Once you go YYYY-MM-DD_HH-MM-SS for photographs, you'll never go back (having the exact millisecond would be neat though)

s/photographs/your documents/g

Really true.. People do many things, because they can

> This is why every project maintainer dreams of being Linus...

Most people who try do it poorly though. You have to be super smart to reject unneeded stuff while still allowing useful features to go through.

No you don't, you just have to fight for it.

Fighting hard isn't en end in itself. We'd have idiots fighting to the bitter end for cruft they happen to be personally invested in. It's really about taking responsibility for all the consequences of your decisions seriously.

Idiots fighting to the bitter end is a large part of what molds society today, unless I have severely missed something. Please educate me if I have.

I'm not sure "it's" really about taking responsibility for all the consequences of your decisions seriously, as much as it is creating the space and mechanisms for your ideas to come to fruition. We cannot "see" the consequences of our actions, but we can create systems that stabilize the world. Perhaps this is what you're talking about?

Ext4, BTRFS, ZFS, NTFS, HFS+, UFS2 all track creation time. Kernel support is past due.

Mods: the title could do with some editing, like making it "wait for", and a space before the year. Thanks.

I agree, it's completely confusing, and even grammatical not.

    > For `btime`, Linus told us to "wait five years"

Would be my suggestion. Or perhaps:

    > Linus told us "wait five years" for `btime`

Another archive of the same mail is http://lkml.iu.edu/hypermail/linux/kernel/1007.2/02325.html

Christ its almost impossible to read that page

Care to elaborate? I didn't have any issues reading that page. Moreover, I don't have any clue what could make it hard to read for others.

The link has been changed by a moderator. I don't know what the original link was, though.

It was this link: http://web.archive.org/web/20100814173517/http://lkml.org/lk...

Good to know. However, I still don't see what grand-grand-grand-parent was complaining about.

Reply on news.ycombinator.com