Is there still no Linux kernel interface to get file creation date?
Clash Royale CLAN TAG#URR8PPP
For a long time, Linux hasn't bothered with file creation dates because none of the file systems it commonly used supported them. However now, 2 file systems commonly used (NTFS and ext4) both record file creation dates.
The stat
command, however, still outputs Birth: -
on an ext4 file system, even though we can see that ext4 has stored the file's create date using debugfs -R 'stat <inode_number>' /dev/file_device
.
When I looked into why this is, I saw that someone else has already recently filed a bug report on it, and the response links through to an upstream issue that simply states "there is no Linux kernel interface at present to get that info [file creation date]". It seems remarkable to me that this is apparently still the case, as people have been requesting that stat
display this info for years (and stat
does output a Birth
field, even though it apparently doesn't support it yet! Did they add it in anticipation?)
So is it still true that there is no Linux kernel interface at present to get file creation date? Is there a plan to implement this ever?
filesystems stat
add a comment |
For a long time, Linux hasn't bothered with file creation dates because none of the file systems it commonly used supported them. However now, 2 file systems commonly used (NTFS and ext4) both record file creation dates.
The stat
command, however, still outputs Birth: -
on an ext4 file system, even though we can see that ext4 has stored the file's create date using debugfs -R 'stat <inode_number>' /dev/file_device
.
When I looked into why this is, I saw that someone else has already recently filed a bug report on it, and the response links through to an upstream issue that simply states "there is no Linux kernel interface at present to get that info [file creation date]". It seems remarkable to me that this is apparently still the case, as people have been requesting that stat
display this info for years (and stat
does output a Birth
field, even though it apparently doesn't support it yet! Did they add it in anticipation?)
So is it still true that there is no Linux kernel interface at present to get file creation date? Is there a plan to implement this ever?
filesystems stat
1
See superuser.com/a/703927/38062 for some background. And enjoy unix.stackexchange.com/a/304245/5132 when you are usingdebugfs
.
– JdeBP
Aug 21 '16 at 11:35
statx()
just merged (Linux release candidate version 4.11-rc1).
– sourcejedi
Mar 9 '17 at 14:52
1
Yay! Only 6 years for Linus to approve :-)
– Jez
Mar 10 '17 at 16:19
ZFS
also records file creation time and allows them to be retrieved via extended attributes.
– schily
Jun 28 '18 at 12:58
add a comment |
For a long time, Linux hasn't bothered with file creation dates because none of the file systems it commonly used supported them. However now, 2 file systems commonly used (NTFS and ext4) both record file creation dates.
The stat
command, however, still outputs Birth: -
on an ext4 file system, even though we can see that ext4 has stored the file's create date using debugfs -R 'stat <inode_number>' /dev/file_device
.
When I looked into why this is, I saw that someone else has already recently filed a bug report on it, and the response links through to an upstream issue that simply states "there is no Linux kernel interface at present to get that info [file creation date]". It seems remarkable to me that this is apparently still the case, as people have been requesting that stat
display this info for years (and stat
does output a Birth
field, even though it apparently doesn't support it yet! Did they add it in anticipation?)
So is it still true that there is no Linux kernel interface at present to get file creation date? Is there a plan to implement this ever?
filesystems stat
For a long time, Linux hasn't bothered with file creation dates because none of the file systems it commonly used supported them. However now, 2 file systems commonly used (NTFS and ext4) both record file creation dates.
The stat
command, however, still outputs Birth: -
on an ext4 file system, even though we can see that ext4 has stored the file's create date using debugfs -R 'stat <inode_number>' /dev/file_device
.
When I looked into why this is, I saw that someone else has already recently filed a bug report on it, and the response links through to an upstream issue that simply states "there is no Linux kernel interface at present to get that info [file creation date]". It seems remarkable to me that this is apparently still the case, as people have been requesting that stat
display this info for years (and stat
does output a Birth
field, even though it apparently doesn't support it yet! Did they add it in anticipation?)
So is it still true that there is no Linux kernel interface at present to get file creation date? Is there a plan to implement this ever?
filesystems stat
filesystems stat
asked Aug 21 '16 at 10:17
JezJez
3382726
3382726
1
See superuser.com/a/703927/38062 for some background. And enjoy unix.stackexchange.com/a/304245/5132 when you are usingdebugfs
.
– JdeBP
Aug 21 '16 at 11:35
statx()
just merged (Linux release candidate version 4.11-rc1).
– sourcejedi
Mar 9 '17 at 14:52
1
Yay! Only 6 years for Linus to approve :-)
– Jez
Mar 10 '17 at 16:19
ZFS
also records file creation time and allows them to be retrieved via extended attributes.
– schily
Jun 28 '18 at 12:58
add a comment |
1
See superuser.com/a/703927/38062 for some background. And enjoy unix.stackexchange.com/a/304245/5132 when you are usingdebugfs
.
– JdeBP
Aug 21 '16 at 11:35
statx()
just merged (Linux release candidate version 4.11-rc1).
– sourcejedi
Mar 9 '17 at 14:52
1
Yay! Only 6 years for Linus to approve :-)
– Jez
Mar 10 '17 at 16:19
ZFS
also records file creation time and allows them to be retrieved via extended attributes.
– schily
Jun 28 '18 at 12:58
1
1
See superuser.com/a/703927/38062 for some background. And enjoy unix.stackexchange.com/a/304245/5132 when you are using
debugfs
.– JdeBP
Aug 21 '16 at 11:35
See superuser.com/a/703927/38062 for some background. And enjoy unix.stackexchange.com/a/304245/5132 when you are using
debugfs
.– JdeBP
Aug 21 '16 at 11:35
statx()
just merged (Linux release candidate version 4.11-rc1).– sourcejedi
Mar 9 '17 at 14:52
statx()
just merged (Linux release candidate version 4.11-rc1).– sourcejedi
Mar 9 '17 at 14:52
1
1
Yay! Only 6 years for Linus to approve :-)
– Jez
Mar 10 '17 at 16:19
Yay! Only 6 years for Linus to approve :-)
– Jez
Mar 10 '17 at 16:19
ZFS
also records file creation time and allows them to be retrieved via extended attributes.– schily
Jun 28 '18 at 12:58
ZFS
also records file creation time and allows them to be retrieved via extended attributes.– schily
Jun 28 '18 at 12:58
add a comment |
3 Answers
3
active
oldest
votes
EDIT: Good news, statx()
has been merged so it should be available in release 4.11.
- https://lwn.net/Articles/716302/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
xstat() work, currently statx(), was revised in 2016.
- http://lwn.net/Articles/685791/
- http://lwn.net/Articles/686106/
The process was a bit more disciplined this time (less bikeshedding, agreement to drop controversial attributes as they can always be added later). Unfortunately there were still objections to the exact interface and I haven't seen any more recent references.
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
add a comment |
because none of the file systems it commonly used supported them
From what I can tell (sorry a bunch of links, memory, and googlage, nothing cohesive enough to list here as a reference), it was never because the underlining systems didn't support creation time attributes, but because none of them could even agree that it was a useful feature.
See http://www.pathname.com/fhs/pub/fhs-2.3.html
POSIX lays out three time stamps. None of them are creation time.
If I remember correctly the argument went something like:
> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness.
> Ok, Ok, *maybe* a couple of these don't suck.
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same.
< Basically everyone had a special case that would work, but not
< one that always works. Fight about fallbacks and other special handling.
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards,
> you can't really come up with a good reason why,
> you can't come up with a good fall back, and
> you can't even come up with a name.
> Sounds like it's specific to the file system to me, and that
> should be "extended data" accessible by tools and not as
> a core stat in the Kernel.
Now a lot of this is memory and reading some old mailing lists. I didn't really sit central to arguments either. I was on a mailing list because of some off shoot work in a fat driver for an embedded Linux system. I mention that because there are surely more authoritative sources then my memory of something I only kinda cared about.
I do remember the big deal being a combination of the fact that no one could come up with a good use case, no one could agree on how to handle the field for the other 40 commonly used file systems that don't support creation time, and even coming up with a name for the field turned into a massive debate.
2
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
1
using something likedebugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.
– ilkkachu
Aug 21 '16 at 16:36
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
add a comment |
The birth time is in several Linux native file systems, not only ext4.
Since version 4.11 of the Linux kernel (April 2017), there's a new statx()
system call to retrieve it. However, the corresponding wrapper function has not been added to the GNU libc yet (as of 2018-06-26. 2019 edit now added in 2.28), and tools like GNU stat
, ls
, find
have not been updated to use it.
You could do it in perl
though with something like:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "" x 0x100; # enough space for a struct statx
for (@ARGV)
# hardcode: AT_FDCWD == -100
# AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
# STATX_BTIME = 0x800 for the mask
# 80: offset of the btime in the struct
syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
or die "$_: $!n";
($t, $n) = unpack("x80QQ", $buf);
$n = sprintf("%09d", $n);
print strftime("%F %T.$n %zn", localtime $t)
' -- "$file"
If your syscall.ph
doesn't have SYS_statx
, you could hardcode it as well. It's 332 on amd64 architectures. Or try:
printf '#include <syscall.h>n__NR_statxn' | gcc -E -xc - | tail -n 1
Now that birth time is rarely useful. It's not the age of the data in the file (data is written to files after they have been created), nor necessarily the time the file appeared by that name in a directory (it could have been created as a different name and renamed or linked there and the content or attributes been changed several times in between).
If Linux did fully supportNFSv4
it would need to support extended attributes and there is a possible entrycrtime
in the extended attributes. Check e.g. the Solarisls.c
source that prints the file creation time withls -l -% crtime
.
– schily
Jun 28 '18 at 12:52
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available throughstatx()
. There's no standard utility which interface tostatx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?
– Stéphane Chazelas
Jun 28 '18 at 13:04
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened viaopenat(fd, ".", O_RDONLY|O_XATTR)
.
– schily
Jun 28 '18 at 13:12
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
|
show 6 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f304779%2fis-there-still-no-linux-kernel-interface-to-get-file-creation-date%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
EDIT: Good news, statx()
has been merged so it should be available in release 4.11.
- https://lwn.net/Articles/716302/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
xstat() work, currently statx(), was revised in 2016.
- http://lwn.net/Articles/685791/
- http://lwn.net/Articles/686106/
The process was a bit more disciplined this time (less bikeshedding, agreement to drop controversial attributes as they can always be added later). Unfortunately there were still objections to the exact interface and I haven't seen any more recent references.
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
add a comment |
EDIT: Good news, statx()
has been merged so it should be available in release 4.11.
- https://lwn.net/Articles/716302/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
xstat() work, currently statx(), was revised in 2016.
- http://lwn.net/Articles/685791/
- http://lwn.net/Articles/686106/
The process was a bit more disciplined this time (less bikeshedding, agreement to drop controversial attributes as they can always be added later). Unfortunately there were still objections to the exact interface and I haven't seen any more recent references.
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
add a comment |
EDIT: Good news, statx()
has been merged so it should be available in release 4.11.
- https://lwn.net/Articles/716302/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
xstat() work, currently statx(), was revised in 2016.
- http://lwn.net/Articles/685791/
- http://lwn.net/Articles/686106/
The process was a bit more disciplined this time (less bikeshedding, agreement to drop controversial attributes as they can always be added later). Unfortunately there were still objections to the exact interface and I haven't seen any more recent references.
EDIT: Good news, statx()
has been merged so it should be available in release 4.11.
- https://lwn.net/Articles/716302/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
xstat() work, currently statx(), was revised in 2016.
- http://lwn.net/Articles/685791/
- http://lwn.net/Articles/686106/
The process was a bit more disciplined this time (less bikeshedding, agreement to drop controversial attributes as they can always be added later). Unfortunately there were still objections to the exact interface and I haven't seen any more recent references.
edited Mar 10 '17 at 16:43
answered Aug 21 '16 at 11:26
sourcejedisourcejedi
25.1k441108
25.1k441108
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
add a comment |
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
The article you linked to isn't available without a subscription. Is it this email? lkml.org/lkml/2017/3/5/149 If so link to that, it's free.
– Jez
Mar 10 '17 at 16:20
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
@Jez fixed. LWN link will become available 7 days later.
– sourcejedi
Mar 10 '17 at 16:44
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
I am running kernel 4.11.2 on Xubuntu 17.04 with latest coreutils (8.27.37-02b65a-dirty) compiled from git source. stat still reports empty birth time. What's wrong?
– shrx
May 22 '17 at 9:33
add a comment |
because none of the file systems it commonly used supported them
From what I can tell (sorry a bunch of links, memory, and googlage, nothing cohesive enough to list here as a reference), it was never because the underlining systems didn't support creation time attributes, but because none of them could even agree that it was a useful feature.
See http://www.pathname.com/fhs/pub/fhs-2.3.html
POSIX lays out three time stamps. None of them are creation time.
If I remember correctly the argument went something like:
> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness.
> Ok, Ok, *maybe* a couple of these don't suck.
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same.
< Basically everyone had a special case that would work, but not
< one that always works. Fight about fallbacks and other special handling.
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards,
> you can't really come up with a good reason why,
> you can't come up with a good fall back, and
> you can't even come up with a name.
> Sounds like it's specific to the file system to me, and that
> should be "extended data" accessible by tools and not as
> a core stat in the Kernel.
Now a lot of this is memory and reading some old mailing lists. I didn't really sit central to arguments either. I was on a mailing list because of some off shoot work in a fat driver for an embedded Linux system. I mention that because there are surely more authoritative sources then my memory of something I only kinda cared about.
I do remember the big deal being a combination of the fact that no one could come up with a good use case, no one could agree on how to handle the field for the other 40 commonly used file systems that don't support creation time, and even coming up with a name for the field turned into a massive debate.
2
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
1
using something likedebugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.
– ilkkachu
Aug 21 '16 at 16:36
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
add a comment |
because none of the file systems it commonly used supported them
From what I can tell (sorry a bunch of links, memory, and googlage, nothing cohesive enough to list here as a reference), it was never because the underlining systems didn't support creation time attributes, but because none of them could even agree that it was a useful feature.
See http://www.pathname.com/fhs/pub/fhs-2.3.html
POSIX lays out three time stamps. None of them are creation time.
If I remember correctly the argument went something like:
> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness.
> Ok, Ok, *maybe* a couple of these don't suck.
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same.
< Basically everyone had a special case that would work, but not
< one that always works. Fight about fallbacks and other special handling.
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards,
> you can't really come up with a good reason why,
> you can't come up with a good fall back, and
> you can't even come up with a name.
> Sounds like it's specific to the file system to me, and that
> should be "extended data" accessible by tools and not as
> a core stat in the Kernel.
Now a lot of this is memory and reading some old mailing lists. I didn't really sit central to arguments either. I was on a mailing list because of some off shoot work in a fat driver for an embedded Linux system. I mention that because there are surely more authoritative sources then my memory of something I only kinda cared about.
I do remember the big deal being a combination of the fact that no one could come up with a good use case, no one could agree on how to handle the field for the other 40 commonly used file systems that don't support creation time, and even coming up with a name for the field turned into a massive debate.
2
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
1
using something likedebugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.
– ilkkachu
Aug 21 '16 at 16:36
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
add a comment |
because none of the file systems it commonly used supported them
From what I can tell (sorry a bunch of links, memory, and googlage, nothing cohesive enough to list here as a reference), it was never because the underlining systems didn't support creation time attributes, but because none of them could even agree that it was a useful feature.
See http://www.pathname.com/fhs/pub/fhs-2.3.html
POSIX lays out three time stamps. None of them are creation time.
If I remember correctly the argument went something like:
> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness.
> Ok, Ok, *maybe* a couple of these don't suck.
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same.
< Basically everyone had a special case that would work, but not
< one that always works. Fight about fallbacks and other special handling.
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards,
> you can't really come up with a good reason why,
> you can't come up with a good fall back, and
> you can't even come up with a name.
> Sounds like it's specific to the file system to me, and that
> should be "extended data" accessible by tools and not as
> a core stat in the Kernel.
Now a lot of this is memory and reading some old mailing lists. I didn't really sit central to arguments either. I was on a mailing list because of some off shoot work in a fat driver for an embedded Linux system. I mention that because there are surely more authoritative sources then my memory of something I only kinda cared about.
I do remember the big deal being a combination of the fact that no one could come up with a good use case, no one could agree on how to handle the field for the other 40 commonly used file systems that don't support creation time, and even coming up with a name for the field turned into a massive debate.
because none of the file systems it commonly used supported them
From what I can tell (sorry a bunch of links, memory, and googlage, nothing cohesive enough to list here as a reference), it was never because the underlining systems didn't support creation time attributes, but because none of them could even agree that it was a useful feature.
See http://www.pathname.com/fhs/pub/fhs-2.3.html
POSIX lays out three time stamps. None of them are creation time.
If I remember correctly the argument went something like:
> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness.
> Ok, Ok, *maybe* a couple of these don't suck.
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same.
< Basically everyone had a special case that would work, but not
< one that always works. Fight about fallbacks and other special handling.
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards,
> you can't really come up with a good reason why,
> you can't come up with a good fall back, and
> you can't even come up with a name.
> Sounds like it's specific to the file system to me, and that
> should be "extended data" accessible by tools and not as
> a core stat in the Kernel.
Now a lot of this is memory and reading some old mailing lists. I didn't really sit central to arguments either. I was on a mailing list because of some off shoot work in a fat driver for an embedded Linux system. I mention that because there are surely more authoritative sources then my memory of something I only kinda cared about.
I do remember the big deal being a combination of the fact that no one could come up with a good use case, no one could agree on how to handle the field for the other 40 commonly used file systems that don't support creation time, and even coming up with a name for the field turned into a massive debate.
answered Aug 21 '16 at 16:13
coteyrcoteyr
3,445921
3,445921
2
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
1
using something likedebugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.
– ilkkachu
Aug 21 '16 at 16:36
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
add a comment |
2
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
1
using something likedebugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.
– ilkkachu
Aug 21 '16 at 16:36
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
2
2
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
Keep in mind that creation time in file systems that support it have always been accessible as an extended stat. It's just that implementation for getting those extended stats vary quite a bit, so there not in tools like ls or find. Argument being is that ls would have to know details of the file system to get the info and that's not what ls is about.
– coteyr
Aug 21 '16 at 16:15
1
1
using something like
debugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.– ilkkachu
Aug 21 '16 at 16:36
using something like
debugfs
to read the field off the disk image isn't much of an interface, and it's going to need privileged access anyway.– ilkkachu
Aug 21 '16 at 16:36
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
Seems like the arguments were because the place to actually change this before implimentation should be consider is in POSIX itself. :)
– Jesse Adelman
Apr 24 '18 at 18:16
add a comment |
The birth time is in several Linux native file systems, not only ext4.
Since version 4.11 of the Linux kernel (April 2017), there's a new statx()
system call to retrieve it. However, the corresponding wrapper function has not been added to the GNU libc yet (as of 2018-06-26. 2019 edit now added in 2.28), and tools like GNU stat
, ls
, find
have not been updated to use it.
You could do it in perl
though with something like:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "" x 0x100; # enough space for a struct statx
for (@ARGV)
# hardcode: AT_FDCWD == -100
# AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
# STATX_BTIME = 0x800 for the mask
# 80: offset of the btime in the struct
syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
or die "$_: $!n";
($t, $n) = unpack("x80QQ", $buf);
$n = sprintf("%09d", $n);
print strftime("%F %T.$n %zn", localtime $t)
' -- "$file"
If your syscall.ph
doesn't have SYS_statx
, you could hardcode it as well. It's 332 on amd64 architectures. Or try:
printf '#include <syscall.h>n__NR_statxn' | gcc -E -xc - | tail -n 1
Now that birth time is rarely useful. It's not the age of the data in the file (data is written to files after they have been created), nor necessarily the time the file appeared by that name in a directory (it could have been created as a different name and renamed or linked there and the content or attributes been changed several times in between).
If Linux did fully supportNFSv4
it would need to support extended attributes and there is a possible entrycrtime
in the extended attributes. Check e.g. the Solarisls.c
source that prints the file creation time withls -l -% crtime
.
– schily
Jun 28 '18 at 12:52
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available throughstatx()
. There's no standard utility which interface tostatx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?
– Stéphane Chazelas
Jun 28 '18 at 13:04
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened viaopenat(fd, ".", O_RDONLY|O_XATTR)
.
– schily
Jun 28 '18 at 13:12
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
|
show 6 more comments
The birth time is in several Linux native file systems, not only ext4.
Since version 4.11 of the Linux kernel (April 2017), there's a new statx()
system call to retrieve it. However, the corresponding wrapper function has not been added to the GNU libc yet (as of 2018-06-26. 2019 edit now added in 2.28), and tools like GNU stat
, ls
, find
have not been updated to use it.
You could do it in perl
though with something like:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "" x 0x100; # enough space for a struct statx
for (@ARGV)
# hardcode: AT_FDCWD == -100
# AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
# STATX_BTIME = 0x800 for the mask
# 80: offset of the btime in the struct
syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
or die "$_: $!n";
($t, $n) = unpack("x80QQ", $buf);
$n = sprintf("%09d", $n);
print strftime("%F %T.$n %zn", localtime $t)
' -- "$file"
If your syscall.ph
doesn't have SYS_statx
, you could hardcode it as well. It's 332 on amd64 architectures. Or try:
printf '#include <syscall.h>n__NR_statxn' | gcc -E -xc - | tail -n 1
Now that birth time is rarely useful. It's not the age of the data in the file (data is written to files after they have been created), nor necessarily the time the file appeared by that name in a directory (it could have been created as a different name and renamed or linked there and the content or attributes been changed several times in between).
If Linux did fully supportNFSv4
it would need to support extended attributes and there is a possible entrycrtime
in the extended attributes. Check e.g. the Solarisls.c
source that prints the file creation time withls -l -% crtime
.
– schily
Jun 28 '18 at 12:52
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available throughstatx()
. There's no standard utility which interface tostatx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?
– Stéphane Chazelas
Jun 28 '18 at 13:04
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened viaopenat(fd, ".", O_RDONLY|O_XATTR)
.
– schily
Jun 28 '18 at 13:12
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
|
show 6 more comments
The birth time is in several Linux native file systems, not only ext4.
Since version 4.11 of the Linux kernel (April 2017), there's a new statx()
system call to retrieve it. However, the corresponding wrapper function has not been added to the GNU libc yet (as of 2018-06-26. 2019 edit now added in 2.28), and tools like GNU stat
, ls
, find
have not been updated to use it.
You could do it in perl
though with something like:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "" x 0x100; # enough space for a struct statx
for (@ARGV)
# hardcode: AT_FDCWD == -100
# AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
# STATX_BTIME = 0x800 for the mask
# 80: offset of the btime in the struct
syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
or die "$_: $!n";
($t, $n) = unpack("x80QQ", $buf);
$n = sprintf("%09d", $n);
print strftime("%F %T.$n %zn", localtime $t)
' -- "$file"
If your syscall.ph
doesn't have SYS_statx
, you could hardcode it as well. It's 332 on amd64 architectures. Or try:
printf '#include <syscall.h>n__NR_statxn' | gcc -E -xc - | tail -n 1
Now that birth time is rarely useful. It's not the age of the data in the file (data is written to files after they have been created), nor necessarily the time the file appeared by that name in a directory (it could have been created as a different name and renamed or linked there and the content or attributes been changed several times in between).
The birth time is in several Linux native file systems, not only ext4.
Since version 4.11 of the Linux kernel (April 2017), there's a new statx()
system call to retrieve it. However, the corresponding wrapper function has not been added to the GNU libc yet (as of 2018-06-26. 2019 edit now added in 2.28), and tools like GNU stat
, ls
, find
have not been updated to use it.
You could do it in perl
though with something like:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "" x 0x100; # enough space for a struct statx
for (@ARGV)
# hardcode: AT_FDCWD == -100
# AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
# STATX_BTIME = 0x800 for the mask
# 80: offset of the btime in the struct
syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
or die "$_: $!n";
($t, $n) = unpack("x80QQ", $buf);
$n = sprintf("%09d", $n);
print strftime("%F %T.$n %zn", localtime $t)
' -- "$file"
If your syscall.ph
doesn't have SYS_statx
, you could hardcode it as well. It's 332 on amd64 architectures. Or try:
printf '#include <syscall.h>n__NR_statxn' | gcc -E -xc - | tail -n 1
Now that birth time is rarely useful. It's not the age of the data in the file (data is written to files after they have been created), nor necessarily the time the file appeared by that name in a directory (it could have been created as a different name and renamed or linked there and the content or attributes been changed several times in between).
edited Feb 20 at 10:03
answered Jun 26 '18 at 16:32
Stéphane ChazelasStéphane Chazelas
310k57584945
310k57584945
If Linux did fully supportNFSv4
it would need to support extended attributes and there is a possible entrycrtime
in the extended attributes. Check e.g. the Solarisls.c
source that prints the file creation time withls -l -% crtime
.
– schily
Jun 28 '18 at 12:52
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available throughstatx()
. There's no standard utility which interface tostatx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?
– Stéphane Chazelas
Jun 28 '18 at 13:04
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened viaopenat(fd, ".", O_RDONLY|O_XATTR)
.
– schily
Jun 28 '18 at 13:12
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
|
show 6 more comments
If Linux did fully supportNFSv4
it would need to support extended attributes and there is a possible entrycrtime
in the extended attributes. Check e.g. the Solarisls.c
source that prints the file creation time withls -l -% crtime
.
– schily
Jun 28 '18 at 12:52
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available throughstatx()
. There's no standard utility which interface tostatx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?
– Stéphane Chazelas
Jun 28 '18 at 13:04
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened viaopenat(fd, ".", O_RDONLY|O_XATTR)
.
– schily
Jun 28 '18 at 13:12
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
If Linux did fully support
NFSv4
it would need to support extended attributes and there is a possible entry crtime
in the extended attributes. Check e.g. the Solaris ls.c
source that prints the file creation time with ls -l -% crtime
.– schily
Jun 28 '18 at 12:52
If Linux did fully support
NFSv4
it would need to support extended attributes and there is a possible entry crtime
in the extended attributes. Check e.g. the Solaris ls.c
source that prints the file creation time with ls -l -% crtime
.– schily
Jun 28 '18 at 12:52
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available through
statx()
. There's no standard utility which interface to statx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?– Stéphane Chazelas
Jun 28 '18 at 13:04
@schily, Linux has extended attributes and ntfs-3g as typically used on opensource OSes like Linux does indeed expose the NTFS creation time as an extended attribute, though since 4.11, I'd expect it's also available through
statx()
. There's no standard utility which interface to statx()
yet on Linux, but retrieving extended attributes has been supported for decades. See How do I get the creation date of a file on an NTFS logical volume?– Stéphane Chazelas
Jun 28 '18 at 13:04
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened via
openat(fd, ".", O_RDONLY|O_XATTR)
.– schily
Jun 28 '18 at 13:12
Well Linux extended attributes are modeled after a POSIX draft that has been withdrawn in 1997. NFSv4 defines a modern extended attribute system, that allows to support NTFS file streams as a subset and that is accessed via the file's attribute directory that is opened via
openat(fd, ".", O_RDONLY|O_XATTR)
.– schily
Jun 28 '18 at 13:12
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, you're confusing with ACLs here. Indeed, Linux has no support for NFSv4 ACLs yet except with an unofficial patch but that has little to do with extended attributes (except that the ACLs would be typically stored as extended attributes). Linux does support extended attributes, which it does indeed use for those POSIX-draft-type ACLs, and for a number of other things. And the API to retrieve those attributes is also used by ntfs-3g to expose the crtime, I suppose in a similar way as on Solaris.
– Stéphane Chazelas
Jun 28 '18 at 13:19
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
@schily, looks like you've added misinformation to Wikipedia on that. Please fix.
– Stéphane Chazelas
Jun 28 '18 at 13:25
|
show 6 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f304779%2fis-there-still-no-linux-kernel-interface-to-get-file-creation-date%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
See superuser.com/a/703927/38062 for some background. And enjoy unix.stackexchange.com/a/304245/5132 when you are using
debugfs
.– JdeBP
Aug 21 '16 at 11:35
statx()
just merged (Linux release candidate version 4.11-rc1).– sourcejedi
Mar 9 '17 at 14:52
1
Yay! Only 6 years for Linus to approve :-)
– Jez
Mar 10 '17 at 16:19
ZFS
also records file creation time and allows them to be retrieved via extended attributes.– schily
Jun 28 '18 at 12:58