Birth is empty on ext4 Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Community Moderator Election Results Why I closed the “Why is Kali so hard” questionGetting file crtime under ext4 file systemWhy is time of birth of file unknown?Get file created/creation time?How do I do a ls and then sort the results by date created?Changing a file's “Date Created” and “Last Modified” attributes to another file'sWhat file systems on Linux store the creation time?How to reliably get timestamp at which the system booted?How to find what device a file is on (and use that in a script)?Does Linux have system calls to access all the features of the file systems it supports?Find the time of the file received in a particular directoryext4 used space (not -m option, not deleted files)Disk problems prevent me from booting, or set the disk to read-only. How do I fix the disk?Ext2 block structure: size of reserved GDT BlocksDisk usage in stat output and inodeFilesystem errors when restoring many filesPartition Errors and Remounts Read-Only when Accessing Specific FileIs the slash (/) part of the name of the Linux root directory?How to calculate the correct size of a loopback device filesystem image for debootstrap?I/O error after power failure, filesystem remounting as read-onlyHow to use ext4 inline_data to store empty directories?

Performance gap between vector<bool> and array

AppleTVs create a chatty alternate WiFi network

What is a fractional matching?

Multiple OR (||) Conditions in If Statement

Why aren't air breathing engines used as small first stages?

Has negative voting ever been officially implemented in elections, or seriously proposed, or even studied?

Is grep documentation about ignoring case wrong, since it doesn't ignore case in filenames?

How do I use the new nonlinear finite element in Mathematica 12 for this equation?

What initially awakened the Balrog?

How often does castling occur in grandmaster games?

Why is my ESD wriststrap failing with nitrile gloves on?

How can I reduce the gap between left and right of cdot with a macro?

How do I find out the mythology and history of my Fortress?

Is it fair for a professor to grade us on the possession of past papers?

How do living politicians protect their readily obtainable signatures from misuse?

How does the math work when buying airline miles?

What would you call this weird metallic apparatus that allows you to lift people?

Significance of Cersei's obsession with elephants?

Disembodied hand growing fangs

What is this clumpy 20-30cm high yellow-flowered plant?

Can a new player join a group only when a new campaign starts?

How come Sam didn't become Lord of Horn Hill?

What was the first language to use conditional keywords?

Why do we bend a book to keep it straight?



Birth is empty on ext4



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)
2019 Community Moderator Election Results
Why I closed the “Why is Kali so hard” questionGetting file crtime under ext4 file systemWhy is time of birth of file unknown?Get file created/creation time?How do I do a ls and then sort the results by date created?Changing a file's “Date Created” and “Last Modified” attributes to another file'sWhat file systems on Linux store the creation time?How to reliably get timestamp at which the system booted?How to find what device a file is on (and use that in a script)?Does Linux have system calls to access all the features of the file systems it supports?Find the time of the file received in a particular directoryext4 used space (not -m option, not deleted files)Disk problems prevent me from booting, or set the disk to read-only. How do I fix the disk?Ext2 block structure: size of reserved GDT BlocksDisk usage in stat output and inodeFilesystem errors when restoring many filesPartition Errors and Remounts Read-Only when Accessing Specific FileIs the slash (/) part of the name of the Linux root directory?How to calculate the correct size of a loopback device filesystem image for debootstrap?I/O error after power failure, filesystem remounting as read-onlyHow to use ext4 inline_data to store empty directories?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








75















I was just reading up on the Birth section of stat and it appears ext4 should support it, but even a file I just created leaves it empty.



 ~ % touch test slave-iv
~ % stat test.pl slave-iv
File: ‘test.pl’
Size: 173 Blocks: 8 IO Block: 4096 regular file
Device: 903h/2307d Inode: 41943086 Links: 1
Access: (0600/-rw-------) Uid: ( 1000/xenoterracide) Gid: ( 100/ users)
Access: 2012-09-22 18:22:16.924634497 -0500
Modify: 2012-09-22 18:22:16.924634497 -0500
Change: 2012-09-22 18:22:16.947967935 -0500
Birth: -

~ % sudo tune2fs -l /dev/md3 | psp4 slave-iv
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: home
Last mounted on: /home
Filesystem UUID: ab2e39fb-acdd-416a-9e10-b501498056de
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: journal_data
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 59736064
Block count: 238920960
Reserved block count: 11946048
Free blocks: 34486248
Free inodes: 59610013
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 967
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 128
RAID stripe width: 256
Flex block group size: 16
Filesystem created: Mon May 31 20:36:30 2010
Last mount time: Sat Oct 6 11:01:01 2012
Last write time: Sat Oct 6 11:01:01 2012
Mount count: 14
Maximum mount count: 34
Last checked: Tue Jul 10 08:26:37 2012
Check interval: 15552000 (6 months)
Next check after: Sun Jan 6 07:26:37 2013
Lifetime writes: 7255 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 55313243
Default directory hash: half_md4
Directory Hash Seed: 442c66e8-8b67-4a8c-92a6-2e2d0c220044
Journal backup: inode blocks


Why doesn't my ext4 partition populate this field?










share|improve this question




























    75















    I was just reading up on the Birth section of stat and it appears ext4 should support it, but even a file I just created leaves it empty.



     ~ % touch test slave-iv
    ~ % stat test.pl slave-iv
    File: ‘test.pl’
    Size: 173 Blocks: 8 IO Block: 4096 regular file
    Device: 903h/2307d Inode: 41943086 Links: 1
    Access: (0600/-rw-------) Uid: ( 1000/xenoterracide) Gid: ( 100/ users)
    Access: 2012-09-22 18:22:16.924634497 -0500
    Modify: 2012-09-22 18:22:16.924634497 -0500
    Change: 2012-09-22 18:22:16.947967935 -0500
    Birth: -

    ~ % sudo tune2fs -l /dev/md3 | psp4 slave-iv
    tune2fs 1.42.5 (29-Jul-2012)
    Filesystem volume name: home
    Last mounted on: /home
    Filesystem UUID: ab2e39fb-acdd-416a-9e10-b501498056de
    Filesystem magic number: 0xEF53
    Filesystem revision #: 1 (dynamic)
    Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
    Filesystem flags: signed_directory_hash
    Default mount options: journal_data
    Filesystem state: clean
    Errors behavior: Continue
    Filesystem OS type: Linux
    Inode count: 59736064
    Block count: 238920960
    Reserved block count: 11946048
    Free blocks: 34486248
    Free inodes: 59610013
    First block: 0
    Block size: 4096
    Fragment size: 4096
    Reserved GDT blocks: 967
    Blocks per group: 32768
    Fragments per group: 32768
    Inodes per group: 8192
    Inode blocks per group: 512
    RAID stride: 128
    RAID stripe width: 256
    Flex block group size: 16
    Filesystem created: Mon May 31 20:36:30 2010
    Last mount time: Sat Oct 6 11:01:01 2012
    Last write time: Sat Oct 6 11:01:01 2012
    Mount count: 14
    Maximum mount count: 34
    Last checked: Tue Jul 10 08:26:37 2012
    Check interval: 15552000 (6 months)
    Next check after: Sun Jan 6 07:26:37 2013
    Lifetime writes: 7255 GB
    Reserved blocks uid: 0 (user root)
    Reserved blocks gid: 0 (group root)
    First inode: 11
    Inode size: 256
    Required extra isize: 28
    Desired extra isize: 28
    Journal inode: 8
    First orphan inode: 55313243
    Default directory hash: half_md4
    Directory Hash Seed: 442c66e8-8b67-4a8c-92a6-2e2d0c220044
    Journal backup: inode blocks


    Why doesn't my ext4 partition populate this field?










    share|improve this question
























      75












      75








      75


      40






      I was just reading up on the Birth section of stat and it appears ext4 should support it, but even a file I just created leaves it empty.



       ~ % touch test slave-iv
      ~ % stat test.pl slave-iv
      File: ‘test.pl’
      Size: 173 Blocks: 8 IO Block: 4096 regular file
      Device: 903h/2307d Inode: 41943086 Links: 1
      Access: (0600/-rw-------) Uid: ( 1000/xenoterracide) Gid: ( 100/ users)
      Access: 2012-09-22 18:22:16.924634497 -0500
      Modify: 2012-09-22 18:22:16.924634497 -0500
      Change: 2012-09-22 18:22:16.947967935 -0500
      Birth: -

      ~ % sudo tune2fs -l /dev/md3 | psp4 slave-iv
      tune2fs 1.42.5 (29-Jul-2012)
      Filesystem volume name: home
      Last mounted on: /home
      Filesystem UUID: ab2e39fb-acdd-416a-9e10-b501498056de
      Filesystem magic number: 0xEF53
      Filesystem revision #: 1 (dynamic)
      Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
      Filesystem flags: signed_directory_hash
      Default mount options: journal_data
      Filesystem state: clean
      Errors behavior: Continue
      Filesystem OS type: Linux
      Inode count: 59736064
      Block count: 238920960
      Reserved block count: 11946048
      Free blocks: 34486248
      Free inodes: 59610013
      First block: 0
      Block size: 4096
      Fragment size: 4096
      Reserved GDT blocks: 967
      Blocks per group: 32768
      Fragments per group: 32768
      Inodes per group: 8192
      Inode blocks per group: 512
      RAID stride: 128
      RAID stripe width: 256
      Flex block group size: 16
      Filesystem created: Mon May 31 20:36:30 2010
      Last mount time: Sat Oct 6 11:01:01 2012
      Last write time: Sat Oct 6 11:01:01 2012
      Mount count: 14
      Maximum mount count: 34
      Last checked: Tue Jul 10 08:26:37 2012
      Check interval: 15552000 (6 months)
      Next check after: Sun Jan 6 07:26:37 2013
      Lifetime writes: 7255 GB
      Reserved blocks uid: 0 (user root)
      Reserved blocks gid: 0 (group root)
      First inode: 11
      Inode size: 256
      Required extra isize: 28
      Desired extra isize: 28
      Journal inode: 8
      First orphan inode: 55313243
      Default directory hash: half_md4
      Directory Hash Seed: 442c66e8-8b67-4a8c-92a6-2e2d0c220044
      Journal backup: inode blocks


      Why doesn't my ext4 partition populate this field?










      share|improve this question














      I was just reading up on the Birth section of stat and it appears ext4 should support it, but even a file I just created leaves it empty.



       ~ % touch test slave-iv
      ~ % stat test.pl slave-iv
      File: ‘test.pl’
      Size: 173 Blocks: 8 IO Block: 4096 regular file
      Device: 903h/2307d Inode: 41943086 Links: 1
      Access: (0600/-rw-------) Uid: ( 1000/xenoterracide) Gid: ( 100/ users)
      Access: 2012-09-22 18:22:16.924634497 -0500
      Modify: 2012-09-22 18:22:16.924634497 -0500
      Change: 2012-09-22 18:22:16.947967935 -0500
      Birth: -

      ~ % sudo tune2fs -l /dev/md3 | psp4 slave-iv
      tune2fs 1.42.5 (29-Jul-2012)
      Filesystem volume name: home
      Last mounted on: /home
      Filesystem UUID: ab2e39fb-acdd-416a-9e10-b501498056de
      Filesystem magic number: 0xEF53
      Filesystem revision #: 1 (dynamic)
      Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
      Filesystem flags: signed_directory_hash
      Default mount options: journal_data
      Filesystem state: clean
      Errors behavior: Continue
      Filesystem OS type: Linux
      Inode count: 59736064
      Block count: 238920960
      Reserved block count: 11946048
      Free blocks: 34486248
      Free inodes: 59610013
      First block: 0
      Block size: 4096
      Fragment size: 4096
      Reserved GDT blocks: 967
      Blocks per group: 32768
      Fragments per group: 32768
      Inodes per group: 8192
      Inode blocks per group: 512
      RAID stride: 128
      RAID stripe width: 256
      Flex block group size: 16
      Filesystem created: Mon May 31 20:36:30 2010
      Last mount time: Sat Oct 6 11:01:01 2012
      Last write time: Sat Oct 6 11:01:01 2012
      Mount count: 14
      Maximum mount count: 34
      Last checked: Tue Jul 10 08:26:37 2012
      Check interval: 15552000 (6 months)
      Next check after: Sun Jan 6 07:26:37 2013
      Lifetime writes: 7255 GB
      Reserved blocks uid: 0 (user root)
      Reserved blocks gid: 0 (group root)
      First inode: 11
      Inode size: 256
      Required extra isize: 28
      Desired extra isize: 28
      Journal inode: 8
      First orphan inode: 55313243
      Default directory hash: half_md4
      Directory Hash Seed: 442c66e8-8b67-4a8c-92a6-2e2d0c220044
      Journal backup: inode blocks


      Why doesn't my ext4 partition populate this field?







      filesystems ext4 stat






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Oct 8 '12 at 3:48









      xenoterracidexenoterracide

      26.2k54159222




      26.2k54159222




















          5 Answers
          5






          active

          oldest

          votes


















          81














          The field gets populated (see below) only coreutils stat does not display it. Apparently they're waiting1 for the xstat() interface.



          coreutils patches - aug. 2012 - TODO




          stat(1) and ls(1) support for birth time. Dependent on xstat() being
          provided by the kernel




          You can get the creation time via debugfs:





          debugfs -R 'stat <inode_number>' DEVICE


          e.g. for my /etc/profile which is on /dev/sda2 (see How to find out what device a file is on):



          stat -c %i /etc/profile
          398264


          debugfs -R 'stat <398264>' /dev/sda2
          debugfs 1.42.5 (29-Jul-2012)
          Inode: 398264 Type: regular Mode: 0644 Flags: 0x80000
          Generation: 2058737571 Version: 0x00000000:00000001
          User: 0 Group: 0 Size: 562
          File ACL: 0 Directory ACL: 0
          Links: 1 Blockcount: 8
          Fragment: Address: 0 Number: 0 Size: 0
          ctime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
          atime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
          mtime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
          crtime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
          Size of extra inode fields: 28
          EXTENTS:
          (0):3308774


          1Linus' reply on LKML thread






          share|improve this answer

























          • sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

            – Sparhawk
            Nov 9 '13 at 3:01






          • 4





            @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

            – jpfleury
            Apr 17 '14 at 2:39











          • Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

            – ctrl-alt-delor
            Aug 11 '14 at 11:27







          • 2





            Can this be used to get creation time of files from a network-mounted filesystem?

            – taranaki
            Sep 20 '18 at 18:32






          • 1





            So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

            – sinekonata
            Mar 1 at 3:10


















          27














          I combined this into a simple shell function:



          get_crtime() 
          for target in "$@"; do
          inode=$(stat -c %i "$target")
          fs=$(df --output=source "$target"


          You can then run it with



          $ get_crtime foo foo/file /etc/
          foo Wed May 21 17:11:08 2014
          foo/file Wed May 21 17:11:27 2014
          /etc/ Wed Aug 1 20:42:03 2012





          share|improve this answer

























          • is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

            – yat0
            Oct 10 '15 at 17:33











          • @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

            – terdon
            Oct 12 '15 at 11:39






          • 1





            Thanks for having all the steps combined into one function.

            – WinEunuuchs2Unix
            Dec 23 '18 at 18:38


















          14














          The xstat function never got merged into mainline. However, a new statx call was proposed later on, and was merged in Linux 4.11. The new statx(2) system call does include a creation time in its return struct.



          However, userland has yet to catch up - it's not easy to call system calls directly in a C program. Typically glibc provides a wrapper that makes the job easy, but glibc added a wrapper for statx(2) only in 2.28 (release August 2018). Luckily, @whotwagner wrote a sample C program that shows how to use the statx(2) system call on x86 and x86-64 systems. Its output is the same format as stat's default, without any formatting options, but it's simple to modify it to print just the birth time. (If you have a new enough glibc, you won't need this - you can use statx directly as described in man 2 statx).



          First, clone it:



          git clone https://github.com/whotwagner/statx-fun


          You can compile the statx.c code, or, if you just want the birth time, create a birth.c in the cloned directory with the following code (which is a minimal version of statx.c printing just the creation timestamp including nanosecond precision):



          #define _GNU_SOURCE
          #define _ATFILE_SOURCE
          #include <stdio.h>
          #include <stdlib.h>
          #include <sys/types.h>
          #include <unistd.h>
          #include <fcntl.h>
          #include "statx.h"
          #include <time.h>
          #include <getopt.h>
          #include <string.h>

          // does not (yet) provide a wrapper for the statx() system call
          #include <sys/syscall.h>

          /* this code works ony with x86 and x86_64 */
          #if __x86_64__
          #define __NR_statx 332
          #else
          #define __NR_statx 383
          #endif

          #define statx(a,b,c,d,e) syscall(__NR_statx,(a),(b),(c),(d),(e))

          int main(int argc, char *argv[])

          int dirfd = AT_FDCWD;
          int flags = AT_SYMLINK_NOFOLLOW;
          unsigned int mask = STATX_ALL;
          struct statx stxbuf;
          long ret = 0;

          int opt = 0;

          while(( opt = getopt(argc, argv, "alfd")) != -1)

          switch(opt)
          case 'a':
          flags


          if (optind >= argc)
          exit(EXIT_FAILURE);


          for (; optind < argc; optind++)
          memset(&stxbuf, 0xbf, sizeof(stxbuf));
          ret = statx(dirfd, argv[optind], flags, mask, &stxbuf);
          if( ret < 0)

          perror("statx");
          return EXIT_FAILURE;

          printf("%lld.%un", *&stxbuf.stx_btime.tv_sec, *&stxbuf.stx_btime.tv_nsec);

          return EXIT_SUCCESS;



          Then:



          $ make birth
          $ ./birth ./birth.c
          1511793291.254337149
          $ ./birth ./birth.c | xargs -I date -d @
          Mon Nov 27 14:34:51 UTC 2017


          In theory this should make the creation time accessible on more filesystems than just the ext* ones (debugfs is a tool for ext2/3/4 filesystems, and unusable on others). It did work for an XFS system, but not for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.




          Now that glibc has support for the statx(2) system call, stat will follow soon and we'll be able to use the plain old stat command for this.






          share|improve this answer
































            3














            There's another case where Birth time will be empty/zero/dash: Ext4's Inode size has to be at least 256bytes to store crtime. The problem occur if you initially created the filesystem smaller than 512MB ( the default Inode size will be 128 bytes, see /etc/mke2fs.conf and mkfs.ext4 manpage).



            stat -c '%n: %w' testfile
            testfile: -


            and/or



            stat -c '%n: %W' testfile
            testfile: 0


            Now check the filesystem inode (is it big enough to store crtime?):



            tune2fs -l $(df . --output=source | grep ^/) | grep "Inode size:"
            Inode size: 128


            Technical information: On the Ext4 Disk Layout page, note that some attributes of the inode tables are beyond 0x80 (128).






            share|improve this answer

























            • Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

              – don_crissti
              Mar 27 '15 at 23:22



















            1














            For what it's worth I was feeling pedantic so wrote a bash wrapper around stat to silently support crtime using debugfs to fetch it from an underlying ext4 filesystem if available. I hope it's robust. Find it here:



            https://github.com/bernd-wechner/Linux-Tools/blob/master/xstat



            Note that a fix is ostensibly on the todo list for Linux as documented in that script. So this wrapper has a nominal lifespan only until that is done and is more an exercise in what's doable.






            share|improve this answer




















            • 1





              Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

              – Stéphane Chazelas
              Jun 3 '17 at 9:35






            • 1





              Awesome! Good news indeed.

              – Bernd Wechner
              Jun 3 '17 at 10:18






            • 5





              With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

              – Nick
              Sep 22 '17 at 9:53











            • "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

              – Bernd Wechner
              Aug 30 '18 at 7:09











            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
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f50177%2fbirth-is-empty-on-ext4%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            5 Answers
            5






            active

            oldest

            votes








            5 Answers
            5






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            81














            The field gets populated (see below) only coreutils stat does not display it. Apparently they're waiting1 for the xstat() interface.



            coreutils patches - aug. 2012 - TODO




            stat(1) and ls(1) support for birth time. Dependent on xstat() being
            provided by the kernel




            You can get the creation time via debugfs:





            debugfs -R 'stat <inode_number>' DEVICE


            e.g. for my /etc/profile which is on /dev/sda2 (see How to find out what device a file is on):



            stat -c %i /etc/profile
            398264


            debugfs -R 'stat <398264>' /dev/sda2
            debugfs 1.42.5 (29-Jul-2012)
            Inode: 398264 Type: regular Mode: 0644 Flags: 0x80000
            Generation: 2058737571 Version: 0x00000000:00000001
            User: 0 Group: 0 Size: 562
            File ACL: 0 Directory ACL: 0
            Links: 1 Blockcount: 8
            Fragment: Address: 0 Number: 0 Size: 0
            ctime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            atime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            mtime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            crtime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            Size of extra inode fields: 28
            EXTENTS:
            (0):3308774


            1Linus' reply on LKML thread






            share|improve this answer

























            • sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

              – Sparhawk
              Nov 9 '13 at 3:01






            • 4





              @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

              – jpfleury
              Apr 17 '14 at 2:39











            • Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

              – ctrl-alt-delor
              Aug 11 '14 at 11:27







            • 2





              Can this be used to get creation time of files from a network-mounted filesystem?

              – taranaki
              Sep 20 '18 at 18:32






            • 1





              So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

              – sinekonata
              Mar 1 at 3:10















            81














            The field gets populated (see below) only coreutils stat does not display it. Apparently they're waiting1 for the xstat() interface.



            coreutils patches - aug. 2012 - TODO




            stat(1) and ls(1) support for birth time. Dependent on xstat() being
            provided by the kernel




            You can get the creation time via debugfs:





            debugfs -R 'stat <inode_number>' DEVICE


            e.g. for my /etc/profile which is on /dev/sda2 (see How to find out what device a file is on):



            stat -c %i /etc/profile
            398264


            debugfs -R 'stat <398264>' /dev/sda2
            debugfs 1.42.5 (29-Jul-2012)
            Inode: 398264 Type: regular Mode: 0644 Flags: 0x80000
            Generation: 2058737571 Version: 0x00000000:00000001
            User: 0 Group: 0 Size: 562
            File ACL: 0 Directory ACL: 0
            Links: 1 Blockcount: 8
            Fragment: Address: 0 Number: 0 Size: 0
            ctime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            atime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            mtime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            crtime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            Size of extra inode fields: 28
            EXTENTS:
            (0):3308774


            1Linus' reply on LKML thread






            share|improve this answer

























            • sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

              – Sparhawk
              Nov 9 '13 at 3:01






            • 4





              @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

              – jpfleury
              Apr 17 '14 at 2:39











            • Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

              – ctrl-alt-delor
              Aug 11 '14 at 11:27







            • 2





              Can this be used to get creation time of files from a network-mounted filesystem?

              – taranaki
              Sep 20 '18 at 18:32






            • 1





              So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

              – sinekonata
              Mar 1 at 3:10













            81












            81








            81







            The field gets populated (see below) only coreutils stat does not display it. Apparently they're waiting1 for the xstat() interface.



            coreutils patches - aug. 2012 - TODO




            stat(1) and ls(1) support for birth time. Dependent on xstat() being
            provided by the kernel




            You can get the creation time via debugfs:





            debugfs -R 'stat <inode_number>' DEVICE


            e.g. for my /etc/profile which is on /dev/sda2 (see How to find out what device a file is on):



            stat -c %i /etc/profile
            398264


            debugfs -R 'stat <398264>' /dev/sda2
            debugfs 1.42.5 (29-Jul-2012)
            Inode: 398264 Type: regular Mode: 0644 Flags: 0x80000
            Generation: 2058737571 Version: 0x00000000:00000001
            User: 0 Group: 0 Size: 562
            File ACL: 0 Directory ACL: 0
            Links: 1 Blockcount: 8
            Fragment: Address: 0 Number: 0 Size: 0
            ctime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            atime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            mtime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            crtime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            Size of extra inode fields: 28
            EXTENTS:
            (0):3308774


            1Linus' reply on LKML thread






            share|improve this answer















            The field gets populated (see below) only coreutils stat does not display it. Apparently they're waiting1 for the xstat() interface.



            coreutils patches - aug. 2012 - TODO




            stat(1) and ls(1) support for birth time. Dependent on xstat() being
            provided by the kernel




            You can get the creation time via debugfs:





            debugfs -R 'stat <inode_number>' DEVICE


            e.g. for my /etc/profile which is on /dev/sda2 (see How to find out what device a file is on):



            stat -c %i /etc/profile
            398264


            debugfs -R 'stat <398264>' /dev/sda2
            debugfs 1.42.5 (29-Jul-2012)
            Inode: 398264 Type: regular Mode: 0644 Flags: 0x80000
            Generation: 2058737571 Version: 0x00000000:00000001
            User: 0 Group: 0 Size: 562
            File ACL: 0 Directory ACL: 0
            Links: 1 Blockcount: 8
            Fragment: Address: 0 Number: 0 Size: 0
            ctime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            atime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            mtime: 0x506b860b:19fa3c34 -- Wed Oct 3 02:25:47 2012
            crtime: 0x50476677:dcd84978 -- Wed Sep 5 16:49:27 2012
            Size of extra inode fields: 28
            EXTENTS:
            (0):3308774


            1Linus' reply on LKML thread







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 13 '17 at 12:37









            Community

            1




            1










            answered Oct 8 '12 at 5:04









            don_crisstidon_crissti

            52.1k15141169




            52.1k15141169












            • sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

              – Sparhawk
              Nov 9 '13 at 3:01






            • 4





              @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

              – jpfleury
              Apr 17 '14 at 2:39











            • Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

              – ctrl-alt-delor
              Aug 11 '14 at 11:27







            • 2





              Can this be used to get creation time of files from a network-mounted filesystem?

              – taranaki
              Sep 20 '18 at 18:32






            • 1





              So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

              – sinekonata
              Mar 1 at 3:10

















            • sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

              – Sparhawk
              Nov 9 '13 at 3:01






            • 4





              @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

              – jpfleury
              Apr 17 '14 at 2:39











            • Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

              – ctrl-alt-delor
              Aug 11 '14 at 11:27







            • 2





              Can this be used to get creation time of files from a network-mounted filesystem?

              – taranaki
              Sep 20 '18 at 18:32






            • 1





              So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

              – sinekonata
              Mar 1 at 3:10
















            sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

            – Sparhawk
            Nov 9 '13 at 3:01





            sudo debugfs -R 'stat /path/to/foo' /dev/sda2 gives me /path/to/foo: File not found by ext2_lookup. stat /path/to/foo works (with Birth empty). Also, ext2?

            – Sparhawk
            Nov 9 '13 at 3:01




            4




            4





            @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

            – jpfleury
            Apr 17 '14 at 2:39





            @Sparhawk: I had this problem too with a file /home/user/path/to/file because /home was on a separate partition. In that case, the path provided to stat must be relative to /home. Example: sudo debugfs -R 'stat user/path/to/file' /dev/sda2. To get rid of the path handling, we can provide to stat the inode number instead of the path: sudo debugfs -R "stat <$(stat -c %i /home/user/path/to/file)>" /dev/sda5

            – jpfleury
            Apr 17 '14 at 2:39













            Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

            – ctrl-alt-delor
            Aug 11 '14 at 11:27






            Equivalent of stat /home/richard is sudo debugfs -R 'stat /richard' /dev/disk/by-label/home — assuming that /home is a separate file-system, and you file-systems are labelled.

            – ctrl-alt-delor
            Aug 11 '14 at 11:27





            2




            2





            Can this be used to get creation time of files from a network-mounted filesystem?

            – taranaki
            Sep 20 '18 at 18:32





            Can this be used to get creation time of files from a network-mounted filesystem?

            – taranaki
            Sep 20 '18 at 18:32




            1




            1





            So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

            – sinekonata
            Mar 1 at 3:10





            So this is not a time stamp that goes beyond the creation of the file system. It means that if a file was created 25 years ago and copied through lots of different physical or mounted systems, there is no way at all to find the information of the date of creation in any of the metadata? So the only way to know when a file was made is to type it into the file name? Or inside the content? Is there any reason for this seemingly odd non implementation?

            – sinekonata
            Mar 1 at 3:10













            27














            I combined this into a simple shell function:



            get_crtime() 
            for target in "$@"; do
            inode=$(stat -c %i "$target")
            fs=$(df --output=source "$target"


            You can then run it with



            $ get_crtime foo foo/file /etc/
            foo Wed May 21 17:11:08 2014
            foo/file Wed May 21 17:11:27 2014
            /etc/ Wed Aug 1 20:42:03 2012





            share|improve this answer

























            • is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

              – yat0
              Oct 10 '15 at 17:33











            • @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

              – terdon
              Oct 12 '15 at 11:39






            • 1





              Thanks for having all the steps combined into one function.

              – WinEunuuchs2Unix
              Dec 23 '18 at 18:38















            27














            I combined this into a simple shell function:



            get_crtime() 
            for target in "$@"; do
            inode=$(stat -c %i "$target")
            fs=$(df --output=source "$target"


            You can then run it with



            $ get_crtime foo foo/file /etc/
            foo Wed May 21 17:11:08 2014
            foo/file Wed May 21 17:11:27 2014
            /etc/ Wed Aug 1 20:42:03 2012





            share|improve this answer

























            • is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

              – yat0
              Oct 10 '15 at 17:33











            • @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

              – terdon
              Oct 12 '15 at 11:39






            • 1





              Thanks for having all the steps combined into one function.

              – WinEunuuchs2Unix
              Dec 23 '18 at 18:38













            27












            27








            27







            I combined this into a simple shell function:



            get_crtime() 
            for target in "$@"; do
            inode=$(stat -c %i "$target")
            fs=$(df --output=source "$target"


            You can then run it with



            $ get_crtime foo foo/file /etc/
            foo Wed May 21 17:11:08 2014
            foo/file Wed May 21 17:11:27 2014
            /etc/ Wed Aug 1 20:42:03 2012





            share|improve this answer















            I combined this into a simple shell function:



            get_crtime() 
            for target in "$@"; do
            inode=$(stat -c %i "$target")
            fs=$(df --output=source "$target"


            You can then run it with



            $ get_crtime foo foo/file /etc/
            foo Wed May 21 17:11:08 2014
            foo/file Wed May 21 17:11:27 2014
            /etc/ Wed Aug 1 20:42:03 2012






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 14 at 11:42









            dessert

            1,262724




            1,262724










            answered May 21 '14 at 15:37









            terdonterdon

            134k33270450




            134k33270450












            • is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

              – yat0
              Oct 10 '15 at 17:33











            • @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

              – terdon
              Oct 12 '15 at 11:39






            • 1





              Thanks for having all the steps combined into one function.

              – WinEunuuchs2Unix
              Dec 23 '18 at 18:38

















            • is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

              – yat0
              Oct 10 '15 at 17:33











            • @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

              – terdon
              Oct 12 '15 at 11:39






            • 1





              Thanks for having all the steps combined into one function.

              – WinEunuuchs2Unix
              Dec 23 '18 at 18:38
















            is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

            – yat0
            Oct 10 '15 at 17:33





            is there a particular reason for not using inode=$(stat -c %i "$target") instead? It's easier and simpler..

            – yat0
            Oct 10 '15 at 17:33













            @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

            – terdon
            Oct 12 '15 at 11:39





            @BrunoCasteleiro basically because that was the one that occurred to me and I like the chance to safely parse ls. It doesn't happen often :). You're right though, stat is probably better, thanks.

            – terdon
            Oct 12 '15 at 11:39




            1




            1





            Thanks for having all the steps combined into one function.

            – WinEunuuchs2Unix
            Dec 23 '18 at 18:38





            Thanks for having all the steps combined into one function.

            – WinEunuuchs2Unix
            Dec 23 '18 at 18:38











            14














            The xstat function never got merged into mainline. However, a new statx call was proposed later on, and was merged in Linux 4.11. The new statx(2) system call does include a creation time in its return struct.



            However, userland has yet to catch up - it's not easy to call system calls directly in a C program. Typically glibc provides a wrapper that makes the job easy, but glibc added a wrapper for statx(2) only in 2.28 (release August 2018). Luckily, @whotwagner wrote a sample C program that shows how to use the statx(2) system call on x86 and x86-64 systems. Its output is the same format as stat's default, without any formatting options, but it's simple to modify it to print just the birth time. (If you have a new enough glibc, you won't need this - you can use statx directly as described in man 2 statx).



            First, clone it:



            git clone https://github.com/whotwagner/statx-fun


            You can compile the statx.c code, or, if you just want the birth time, create a birth.c in the cloned directory with the following code (which is a minimal version of statx.c printing just the creation timestamp including nanosecond precision):



            #define _GNU_SOURCE
            #define _ATFILE_SOURCE
            #include <stdio.h>
            #include <stdlib.h>
            #include <sys/types.h>
            #include <unistd.h>
            #include <fcntl.h>
            #include "statx.h"
            #include <time.h>
            #include <getopt.h>
            #include <string.h>

            // does not (yet) provide a wrapper for the statx() system call
            #include <sys/syscall.h>

            /* this code works ony with x86 and x86_64 */
            #if __x86_64__
            #define __NR_statx 332
            #else
            #define __NR_statx 383
            #endif

            #define statx(a,b,c,d,e) syscall(__NR_statx,(a),(b),(c),(d),(e))

            int main(int argc, char *argv[])

            int dirfd = AT_FDCWD;
            int flags = AT_SYMLINK_NOFOLLOW;
            unsigned int mask = STATX_ALL;
            struct statx stxbuf;
            long ret = 0;

            int opt = 0;

            while(( opt = getopt(argc, argv, "alfd")) != -1)

            switch(opt)
            case 'a':
            flags


            if (optind >= argc)
            exit(EXIT_FAILURE);


            for (; optind < argc; optind++)
            memset(&stxbuf, 0xbf, sizeof(stxbuf));
            ret = statx(dirfd, argv[optind], flags, mask, &stxbuf);
            if( ret < 0)

            perror("statx");
            return EXIT_FAILURE;

            printf("%lld.%un", *&stxbuf.stx_btime.tv_sec, *&stxbuf.stx_btime.tv_nsec);

            return EXIT_SUCCESS;



            Then:



            $ make birth
            $ ./birth ./birth.c
            1511793291.254337149
            $ ./birth ./birth.c | xargs -I date -d @
            Mon Nov 27 14:34:51 UTC 2017


            In theory this should make the creation time accessible on more filesystems than just the ext* ones (debugfs is a tool for ext2/3/4 filesystems, and unusable on others). It did work for an XFS system, but not for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.




            Now that glibc has support for the statx(2) system call, stat will follow soon and we'll be able to use the plain old stat command for this.






            share|improve this answer





























              14














              The xstat function never got merged into mainline. However, a new statx call was proposed later on, and was merged in Linux 4.11. The new statx(2) system call does include a creation time in its return struct.



              However, userland has yet to catch up - it's not easy to call system calls directly in a C program. Typically glibc provides a wrapper that makes the job easy, but glibc added a wrapper for statx(2) only in 2.28 (release August 2018). Luckily, @whotwagner wrote a sample C program that shows how to use the statx(2) system call on x86 and x86-64 systems. Its output is the same format as stat's default, without any formatting options, but it's simple to modify it to print just the birth time. (If you have a new enough glibc, you won't need this - you can use statx directly as described in man 2 statx).



              First, clone it:



              git clone https://github.com/whotwagner/statx-fun


              You can compile the statx.c code, or, if you just want the birth time, create a birth.c in the cloned directory with the following code (which is a minimal version of statx.c printing just the creation timestamp including nanosecond precision):



              #define _GNU_SOURCE
              #define _ATFILE_SOURCE
              #include <stdio.h>
              #include <stdlib.h>
              #include <sys/types.h>
              #include <unistd.h>
              #include <fcntl.h>
              #include "statx.h"
              #include <time.h>
              #include <getopt.h>
              #include <string.h>

              // does not (yet) provide a wrapper for the statx() system call
              #include <sys/syscall.h>

              /* this code works ony with x86 and x86_64 */
              #if __x86_64__
              #define __NR_statx 332
              #else
              #define __NR_statx 383
              #endif

              #define statx(a,b,c,d,e) syscall(__NR_statx,(a),(b),(c),(d),(e))

              int main(int argc, char *argv[])

              int dirfd = AT_FDCWD;
              int flags = AT_SYMLINK_NOFOLLOW;
              unsigned int mask = STATX_ALL;
              struct statx stxbuf;
              long ret = 0;

              int opt = 0;

              while(( opt = getopt(argc, argv, "alfd")) != -1)

              switch(opt)
              case 'a':
              flags


              if (optind >= argc)
              exit(EXIT_FAILURE);


              for (; optind < argc; optind++)
              memset(&stxbuf, 0xbf, sizeof(stxbuf));
              ret = statx(dirfd, argv[optind], flags, mask, &stxbuf);
              if( ret < 0)

              perror("statx");
              return EXIT_FAILURE;

              printf("%lld.%un", *&stxbuf.stx_btime.tv_sec, *&stxbuf.stx_btime.tv_nsec);

              return EXIT_SUCCESS;



              Then:



              $ make birth
              $ ./birth ./birth.c
              1511793291.254337149
              $ ./birth ./birth.c | xargs -I date -d @
              Mon Nov 27 14:34:51 UTC 2017


              In theory this should make the creation time accessible on more filesystems than just the ext* ones (debugfs is a tool for ext2/3/4 filesystems, and unusable on others). It did work for an XFS system, but not for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.




              Now that glibc has support for the statx(2) system call, stat will follow soon and we'll be able to use the plain old stat command for this.






              share|improve this answer



























                14












                14








                14







                The xstat function never got merged into mainline. However, a new statx call was proposed later on, and was merged in Linux 4.11. The new statx(2) system call does include a creation time in its return struct.



                However, userland has yet to catch up - it's not easy to call system calls directly in a C program. Typically glibc provides a wrapper that makes the job easy, but glibc added a wrapper for statx(2) only in 2.28 (release August 2018). Luckily, @whotwagner wrote a sample C program that shows how to use the statx(2) system call on x86 and x86-64 systems. Its output is the same format as stat's default, without any formatting options, but it's simple to modify it to print just the birth time. (If you have a new enough glibc, you won't need this - you can use statx directly as described in man 2 statx).



                First, clone it:



                git clone https://github.com/whotwagner/statx-fun


                You can compile the statx.c code, or, if you just want the birth time, create a birth.c in the cloned directory with the following code (which is a minimal version of statx.c printing just the creation timestamp including nanosecond precision):



                #define _GNU_SOURCE
                #define _ATFILE_SOURCE
                #include <stdio.h>
                #include <stdlib.h>
                #include <sys/types.h>
                #include <unistd.h>
                #include <fcntl.h>
                #include "statx.h"
                #include <time.h>
                #include <getopt.h>
                #include <string.h>

                // does not (yet) provide a wrapper for the statx() system call
                #include <sys/syscall.h>

                /* this code works ony with x86 and x86_64 */
                #if __x86_64__
                #define __NR_statx 332
                #else
                #define __NR_statx 383
                #endif

                #define statx(a,b,c,d,e) syscall(__NR_statx,(a),(b),(c),(d),(e))

                int main(int argc, char *argv[])

                int dirfd = AT_FDCWD;
                int flags = AT_SYMLINK_NOFOLLOW;
                unsigned int mask = STATX_ALL;
                struct statx stxbuf;
                long ret = 0;

                int opt = 0;

                while(( opt = getopt(argc, argv, "alfd")) != -1)

                switch(opt)
                case 'a':
                flags


                if (optind >= argc)
                exit(EXIT_FAILURE);


                for (; optind < argc; optind++)
                memset(&stxbuf, 0xbf, sizeof(stxbuf));
                ret = statx(dirfd, argv[optind], flags, mask, &stxbuf);
                if( ret < 0)

                perror("statx");
                return EXIT_FAILURE;

                printf("%lld.%un", *&stxbuf.stx_btime.tv_sec, *&stxbuf.stx_btime.tv_nsec);

                return EXIT_SUCCESS;



                Then:



                $ make birth
                $ ./birth ./birth.c
                1511793291.254337149
                $ ./birth ./birth.c | xargs -I date -d @
                Mon Nov 27 14:34:51 UTC 2017


                In theory this should make the creation time accessible on more filesystems than just the ext* ones (debugfs is a tool for ext2/3/4 filesystems, and unusable on others). It did work for an XFS system, but not for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.




                Now that glibc has support for the statx(2) system call, stat will follow soon and we'll be able to use the plain old stat command for this.






                share|improve this answer















                The xstat function never got merged into mainline. However, a new statx call was proposed later on, and was merged in Linux 4.11. The new statx(2) system call does include a creation time in its return struct.



                However, userland has yet to catch up - it's not easy to call system calls directly in a C program. Typically glibc provides a wrapper that makes the job easy, but glibc added a wrapper for statx(2) only in 2.28 (release August 2018). Luckily, @whotwagner wrote a sample C program that shows how to use the statx(2) system call on x86 and x86-64 systems. Its output is the same format as stat's default, without any formatting options, but it's simple to modify it to print just the birth time. (If you have a new enough glibc, you won't need this - you can use statx directly as described in man 2 statx).



                First, clone it:



                git clone https://github.com/whotwagner/statx-fun


                You can compile the statx.c code, or, if you just want the birth time, create a birth.c in the cloned directory with the following code (which is a minimal version of statx.c printing just the creation timestamp including nanosecond precision):



                #define _GNU_SOURCE
                #define _ATFILE_SOURCE
                #include <stdio.h>
                #include <stdlib.h>
                #include <sys/types.h>
                #include <unistd.h>
                #include <fcntl.h>
                #include "statx.h"
                #include <time.h>
                #include <getopt.h>
                #include <string.h>

                // does not (yet) provide a wrapper for the statx() system call
                #include <sys/syscall.h>

                /* this code works ony with x86 and x86_64 */
                #if __x86_64__
                #define __NR_statx 332
                #else
                #define __NR_statx 383
                #endif

                #define statx(a,b,c,d,e) syscall(__NR_statx,(a),(b),(c),(d),(e))

                int main(int argc, char *argv[])

                int dirfd = AT_FDCWD;
                int flags = AT_SYMLINK_NOFOLLOW;
                unsigned int mask = STATX_ALL;
                struct statx stxbuf;
                long ret = 0;

                int opt = 0;

                while(( opt = getopt(argc, argv, "alfd")) != -1)

                switch(opt)
                case 'a':
                flags


                if (optind >= argc)
                exit(EXIT_FAILURE);


                for (; optind < argc; optind++)
                memset(&stxbuf, 0xbf, sizeof(stxbuf));
                ret = statx(dirfd, argv[optind], flags, mask, &stxbuf);
                if( ret < 0)

                perror("statx");
                return EXIT_FAILURE;

                printf("%lld.%un", *&stxbuf.stx_btime.tv_sec, *&stxbuf.stx_btime.tv_nsec);

                return EXIT_SUCCESS;



                Then:



                $ make birth
                $ ./birth ./birth.c
                1511793291.254337149
                $ ./birth ./birth.c | xargs -I date -d @
                Mon Nov 27 14:34:51 UTC 2017


                In theory this should make the creation time accessible on more filesystems than just the ext* ones (debugfs is a tool for ext2/3/4 filesystems, and unusable on others). It did work for an XFS system, but not for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.




                Now that glibc has support for the statx(2) system call, stat will follow soon and we'll be able to use the plain old stat command for this.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Nov 20 '18 at 9:59

























                answered Nov 27 '17 at 15:24









                murumuru

                38k590166




                38k590166





















                    3














                    There's another case where Birth time will be empty/zero/dash: Ext4's Inode size has to be at least 256bytes to store crtime. The problem occur if you initially created the filesystem smaller than 512MB ( the default Inode size will be 128 bytes, see /etc/mke2fs.conf and mkfs.ext4 manpage).



                    stat -c '%n: %w' testfile
                    testfile: -


                    and/or



                    stat -c '%n: %W' testfile
                    testfile: 0


                    Now check the filesystem inode (is it big enough to store crtime?):



                    tune2fs -l $(df . --output=source | grep ^/) | grep "Inode size:"
                    Inode size: 128


                    Technical information: On the Ext4 Disk Layout page, note that some attributes of the inode tables are beyond 0x80 (128).






                    share|improve this answer

























                    • Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

                      – don_crissti
                      Mar 27 '15 at 23:22
















                    3














                    There's another case where Birth time will be empty/zero/dash: Ext4's Inode size has to be at least 256bytes to store crtime. The problem occur if you initially created the filesystem smaller than 512MB ( the default Inode size will be 128 bytes, see /etc/mke2fs.conf and mkfs.ext4 manpage).



                    stat -c '%n: %w' testfile
                    testfile: -


                    and/or



                    stat -c '%n: %W' testfile
                    testfile: 0


                    Now check the filesystem inode (is it big enough to store crtime?):



                    tune2fs -l $(df . --output=source | grep ^/) | grep "Inode size:"
                    Inode size: 128


                    Technical information: On the Ext4 Disk Layout page, note that some attributes of the inode tables are beyond 0x80 (128).






                    share|improve this answer

























                    • Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

                      – don_crissti
                      Mar 27 '15 at 23:22














                    3












                    3








                    3







                    There's another case where Birth time will be empty/zero/dash: Ext4's Inode size has to be at least 256bytes to store crtime. The problem occur if you initially created the filesystem smaller than 512MB ( the default Inode size will be 128 bytes, see /etc/mke2fs.conf and mkfs.ext4 manpage).



                    stat -c '%n: %w' testfile
                    testfile: -


                    and/or



                    stat -c '%n: %W' testfile
                    testfile: 0


                    Now check the filesystem inode (is it big enough to store crtime?):



                    tune2fs -l $(df . --output=source | grep ^/) | grep "Inode size:"
                    Inode size: 128


                    Technical information: On the Ext4 Disk Layout page, note that some attributes of the inode tables are beyond 0x80 (128).






                    share|improve this answer















                    There's another case where Birth time will be empty/zero/dash: Ext4's Inode size has to be at least 256bytes to store crtime. The problem occur if you initially created the filesystem smaller than 512MB ( the default Inode size will be 128 bytes, see /etc/mke2fs.conf and mkfs.ext4 manpage).



                    stat -c '%n: %w' testfile
                    testfile: -


                    and/or



                    stat -c '%n: %W' testfile
                    testfile: 0


                    Now check the filesystem inode (is it big enough to store crtime?):



                    tune2fs -l $(df . --output=source | grep ^/) | grep "Inode size:"
                    Inode size: 128


                    Technical information: On the Ext4 Disk Layout page, note that some attributes of the inode tables are beyond 0x80 (128).







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Mar 28 '15 at 6:14

























                    answered Mar 27 '15 at 20:59









                    Franklin PiatFranklin Piat

                    1,9082028




                    1,9082028












                    • Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

                      – don_crissti
                      Mar 27 '15 at 23:22


















                    • Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

                      – don_crissti
                      Mar 27 '15 at 23:22

















                    Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

                    – don_crissti
                    Mar 27 '15 at 23:22






                    Correct (I remember reading about this on vger). The 512MB limit is defined in mke2fs.c at line 1275

                    – don_crissti
                    Mar 27 '15 at 23:22












                    1














                    For what it's worth I was feeling pedantic so wrote a bash wrapper around stat to silently support crtime using debugfs to fetch it from an underlying ext4 filesystem if available. I hope it's robust. Find it here:



                    https://github.com/bernd-wechner/Linux-Tools/blob/master/xstat



                    Note that a fix is ostensibly on the todo list for Linux as documented in that script. So this wrapper has a nominal lifespan only until that is done and is more an exercise in what's doable.






                    share|improve this answer




















                    • 1





                      Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

                      – Stéphane Chazelas
                      Jun 3 '17 at 9:35






                    • 1





                      Awesome! Good news indeed.

                      – Bernd Wechner
                      Jun 3 '17 at 10:18






                    • 5





                      With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

                      – Nick
                      Sep 22 '17 at 9:53











                    • "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

                      – Bernd Wechner
                      Aug 30 '18 at 7:09















                    1














                    For what it's worth I was feeling pedantic so wrote a bash wrapper around stat to silently support crtime using debugfs to fetch it from an underlying ext4 filesystem if available. I hope it's robust. Find it here:



                    https://github.com/bernd-wechner/Linux-Tools/blob/master/xstat



                    Note that a fix is ostensibly on the todo list for Linux as documented in that script. So this wrapper has a nominal lifespan only until that is done and is more an exercise in what's doable.






                    share|improve this answer




















                    • 1





                      Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

                      – Stéphane Chazelas
                      Jun 3 '17 at 9:35






                    • 1





                      Awesome! Good news indeed.

                      – Bernd Wechner
                      Jun 3 '17 at 10:18






                    • 5





                      With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

                      – Nick
                      Sep 22 '17 at 9:53











                    • "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

                      – Bernd Wechner
                      Aug 30 '18 at 7:09













                    1












                    1








                    1







                    For what it's worth I was feeling pedantic so wrote a bash wrapper around stat to silently support crtime using debugfs to fetch it from an underlying ext4 filesystem if available. I hope it's robust. Find it here:



                    https://github.com/bernd-wechner/Linux-Tools/blob/master/xstat



                    Note that a fix is ostensibly on the todo list for Linux as documented in that script. So this wrapper has a nominal lifespan only until that is done and is more an exercise in what's doable.






                    share|improve this answer















                    For what it's worth I was feeling pedantic so wrote a bash wrapper around stat to silently support crtime using debugfs to fetch it from an underlying ext4 filesystem if available. I hope it's robust. Find it here:



                    https://github.com/bernd-wechner/Linux-Tools/blob/master/xstat



                    Note that a fix is ostensibly on the todo list for Linux as documented in that script. So this wrapper has a nominal lifespan only until that is done and is more an exercise in what's doable.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Jun 3 '17 at 10:18

























                    answered Jun 3 '17 at 9:31









                    Bernd WechnerBernd Wechner

                    1113




                    1113







                    • 1





                      Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

                      – Stéphane Chazelas
                      Jun 3 '17 at 9:35






                    • 1





                      Awesome! Good news indeed.

                      – Bernd Wechner
                      Jun 3 '17 at 10:18






                    • 5





                      With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

                      – Nick
                      Sep 22 '17 at 9:53











                    • "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

                      – Bernd Wechner
                      Aug 30 '18 at 7:09












                    • 1





                      Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

                      – Stéphane Chazelas
                      Jun 3 '17 at 9:35






                    • 1





                      Awesome! Good news indeed.

                      – Bernd Wechner
                      Jun 3 '17 at 10:18






                    • 5





                      With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

                      – Nick
                      Sep 22 '17 at 9:53











                    • "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

                      – Bernd Wechner
                      Aug 30 '18 at 7:09







                    1




                    1





                    Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

                    – Stéphane Chazelas
                    Jun 3 '17 at 9:35





                    Note that xstat() has eventually been added to Linux, so it's only a matter of time before the GNU libc and find add support for it.

                    – Stéphane Chazelas
                    Jun 3 '17 at 9:35




                    1




                    1





                    Awesome! Good news indeed.

                    – Bernd Wechner
                    Jun 3 '17 at 10:18





                    Awesome! Good news indeed.

                    – Bernd Wechner
                    Jun 3 '17 at 10:18




                    5




                    5





                    With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

                    – Nick
                    Sep 22 '17 at 9:53





                    With apologies for being pedantic, you seem not to understand the meaning of "pedantic".

                    – Nick
                    Sep 22 '17 at 9:53













                    "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

                    – Bernd Wechner
                    Aug 30 '18 at 7:09





                    "overly concerned with minute details or formalisms" - as in, the accepted answer is fine, but ... let's formalise it. ;-)

                    – Bernd Wechner
                    Aug 30 '18 at 7:09

















                    draft saved

                    draft discarded
















































                    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.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f50177%2fbirth-is-empty-on-ext4%23new-answer', 'question_page');

                    );

                    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







                    Popular posts from this blog

                    Àrd-bhaile Cathair chruinne/Baile mòr cruinne | Artagailean ceangailte | Clàr-taice na seòladaireachd

                    대한민국 목차 국명 지리 역사 정치 국방 경제 사회 문화 국제 순위 관련 항목 각주 외부 링크 둘러보기 메뉴북위 37° 34′ 08″ 동경 126° 58′ 36″ / 북위 37.568889° 동경 126.976667°  / 37.568889; 126.976667ehThe Korean Repository문단을 편집문단을 편집추가해Clarkson PLC 사Report for Selected Countries and Subjects-Korea“Human Development Index and its components: P.198”“http://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EB%8C%80%ED%95%9C%EB%AF%BC%EA%B5%AD%EA%B5%AD%EA%B8%B0%EB%B2%95”"한국은 국제법상 한반도 유일 합법정부 아니다" - 오마이뉴스 모바일Report for Selected Countries and Subjects: South Korea격동의 역사와 함께한 조선일보 90년 : 조선일보 인수해 혁신시킨 신석우, 임시정부 때는 '대한민국' 국호(國號) 정해《우리가 몰랐던 우리 역사: 나라 이름의 비밀을 찾아가는 역사 여행》“남북 공식호칭 ‘남한’‘북한’으로 쓴다”“Corea 대 Korea, 누가 이긴 거야?”국내기후자료 - 한국[김대중 前 대통령 서거] 과감한 구조개혁 'DJ노믹스'로 최단기간 환란극복 :: 네이버 뉴스“이라크 "韓-쿠르드 유전개발 MOU 승인 안해"(종합)”“해외 우리국민 추방사례 43%가 일본”차기전차 K2'흑표'의 세계 최고 전력 분석, 쿠키뉴스 엄기영, 2007-03-02두산인프라, 헬기잡는 장갑차 'K21'...내년부터 공급, 고뉴스 이대준, 2008-10-30과거 내용 찾기mk 뉴스 - 구매력 기준으로 보면 한국 1인당 소득 3만弗과거 내용 찾기"The N-11: More Than an Acronym"Archived조선일보 최우석, 2008-11-01Global 500 2008: Countries - South Korea“몇년째 '시한폭탄'... 가계부채, 올해는 터질까”가구당 부채 5000만원 처음 넘어서“‘빚’으로 내몰리는 사회.. 위기의 가계대출”“[경제365] 공공부문 부채 급증…800조 육박”“"소득 양극화 다소 완화...불평등은 여전"”“공정사회·공생발전 한참 멀었네”iSuppli,08年2QのDRAMシェア・ランキングを発表(08/8/11)South Korea dominates shipbuilding industry | Stock Market News & Stocks to Watch from StraightStocks한국 자동차 생산, 3년 연속 세계 5위자동차수출 '현대-삼성 웃고 기아-대우-쌍용은 울고' 과거 내용 찾기동반성장위 창립 1주년 맞아Archived"중기적합 3개업종 합의 무시한 채 선정"李대통령, 사업 무분별 확장 소상공인 생계 위협 질타삼성-LG, 서민업종인 빵·분식사업 잇따라 철수상생은 뒷전…SSM ‘몸집 불리기’ 혈안Archived“경부고속도에 '아시안하이웨이' 표지판”'철의 실크로드' 앞서 '말(言)의 실크로드'부터, 프레시안 정창현, 2008-10-01“'서울 지하철은 안전한가?'”“서울시 “올해 안에 모든 지하철역 스크린도어 설치””“부산지하철 1,2호선 승강장 안전펜스 설치 완료”“전교조, 정부 노조 통계서 처음 빠져”“[Weekly BIZ] 도요타 '제로 이사회'가 리콜 사태 불러들였다”“S Korea slams high tuition costs”““정치가 여론 양극화 부채질… 합리주의 절실””“〈"`촛불집회'는 민주주의의 질적 변화 상징"〉”““촛불집회가 민주주의 왜곡 초래””“국민 65%, "한국 노사관계 대립적"”“한국 국가경쟁력 27위‥노사관계 '꼴찌'”“제대로 형성되지 않은 대한민국 이념지형”“[신년기획-갈등의 시대] 갈등지수 OECD 4위…사회적 손실 GDP 27% 무려 300조”“2012 총선-대선의 키워드는 '국민과 소통'”“한국 삶의 질 27위, 2000년과 2008년 연속 하위권 머물러”“[해피 코리아] 행복점수 68점…해외 평가선 '낙제점'”“한국 어린이·청소년 행복지수 3년 연속 OECD ‘꼴찌’”“한국 이혼율 OECD중 8위”“[통계청] 한국 이혼율 OECD 4위”“오피니언 [이렇게 생각한다] `부부의 날` 에 돌아본 이혼율 1위 한국”“Suicide Rates by Country, Global Health Observatory Data Repository.”“1. 또 다른 차별”“오피니언 [편집자에게] '왕따'와 '패거리 정치' 심리는 닮은꼴”“[미래한국리포트] 무한경쟁에 빠진 대한민국”“대학생 98% "외모가 경쟁력이라는 말 동의"”“특급호텔 웨딩·200만원대 유모차… "남보다 더…" 호화病, 고질병 됐다”“[스트레스 공화국] ① 경쟁사회, 스트레스 쌓인다”““매일 30여명 자살 한국, 의사보다 무속인에…””“"자살 부르는 '우울증', 환자 중 85% 치료 안 받아"”“정신병원을 가다”“대한민국도 ‘묻지마 범죄’,안전지대 아니다”“유엔 "학생 '성적 지향'에 따른 차별 금지하라"”“유엔아동권리위원회 보고서 및 번역본 원문”“고졸 성공스토리 담은 '제빵왕 김탁구' 드라마 나온다”“‘빛 좋은 개살구’ 고졸 취업…실습 대신 착취”원본 문서“정신건강, 사회적 편견부터 고쳐드립니다”‘소통’과 ‘행복’에 목 마른 사회가 잠들어 있던 ‘심리학’ 깨웠다“[포토] 사유리-곽금주 교수의 유쾌한 심리상담”“"올해 한국인 평균 영화관람횟수 세계 1위"(종합)”“[게임연중기획] 게임은 문화다-여가활동 1순위 게임”“영화속 ‘영어 지상주의’ …“왠지 씁쓸한데””“2월 `신문 부수 인증기관` 지정..방송법 후속작업”“무료신문 성장동력 ‘차별성’과 ‘갈등해소’”대한민국 국회 법률지식정보시스템"Pew Research Center's Religion & Public Life Project: South Korea"“amp;vwcd=MT_ZTITLE&path=인구·가구%20>%20인구총조사%20>%20인구부문%20>%20 총조사인구(2005)%20>%20전수부문&oper_YN=Y&item=&keyword=종교별%20인구& amp;lang_mode=kor&list_id= 2005년 통계청 인구 총조사”원본 문서“한국인이 좋아하는 취미와 운동 (2004-2009)”“한국인이 좋아하는 취미와 운동 (2004-2014)”Archived“한국, `부분적 언론자유국' 강등〈프리덤하우스〉”“국경없는기자회 "한국, 인터넷감시 대상국"”“한국, 조선산업 1위 유지(S. Korea Stays Top Shipbuilding Nation) RZD-Partner Portal”원본 문서“한국, 4년 만에 ‘선박건조 1위’”“옛 마산시,인터넷속도 세계 1위”“"한국 초고속 인터넷망 세계1위"”“인터넷·휴대폰 요금, 외국보다 훨씬 비싸”“한국 관세행정 6년 연속 세계 '1위'”“한국 교통사고 사망자 수 OECD 회원국 중 2위”“결핵 후진국' 한국, 환자가 급증한 이유는”“수술은 신중해야… 자칫하면 생명 위협”대한민국분류대한민국의 지도대한민국 정부대표 다국어포털대한민국 전자정부대한민국 국회한국방송공사about korea and information korea브리태니커 백과사전(한국편)론리플래닛의 정보(한국편)CIA의 세계 정보(한국편)마리암 부디아 (Mariam Budia),『한국: 하늘이 내린 한 폭의 그림』, 서울: 트랜스라틴 19호 (2012년 3월)대한민국ehehehehehehehehehehehehehehWorldCat132441370n791268020000 0001 2308 81034078029-6026373548cb11863345f(데이터)00573706ge128495

                    Cannot Extend partition with GParted The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Community Moderator Election ResultsCan't increase partition size with GParted?GParted doesn't recognize the unallocated space after my current partitionWhat is the best way to add unallocated space located before to Ubuntu 12.04 partition with GParted live?I can't figure out how to extend my Arch home partition into free spaceGparted Linux Mint 18.1 issueTrying to extend but swap partition is showing as Unknown in Gparted, shows proper from fdiskRearrange partitions in gparted to extend a partitionUnable to extend partition even though unallocated space is next to it using GPartedAllocate free space to root partitiongparted: how to merge unallocated space with a partition