How do I find the creation time of a file?
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
51
down vote
favorite
I need to find the creation time of a file, when I read some articles about this issue, all mentioned that there is no solution (like Site1, Site2).
When I tried the stat
command, it states Birth: -
.
So how can I find the creation time of a file?
filesystem metadata stat
add a comment |Â
up vote
51
down vote
favorite
I need to find the creation time of a file, when I read some articles about this issue, all mentioned that there is no solution (like Site1, Site2).
When I tried the stat
command, it states Birth: -
.
So how can I find the creation time of a file?
filesystem metadata stat
1
Keep in mind that the 'creation time' of a file is not guaranteed to be accurate. There are many ways to 'fudge' the creation dates on a file.
â Thomas Wardâ¦
Nov 27 '17 at 15:00
add a comment |Â
up vote
51
down vote
favorite
up vote
51
down vote
favorite
I need to find the creation time of a file, when I read some articles about this issue, all mentioned that there is no solution (like Site1, Site2).
When I tried the stat
command, it states Birth: -
.
So how can I find the creation time of a file?
filesystem metadata stat
I need to find the creation time of a file, when I read some articles about this issue, all mentioned that there is no solution (like Site1, Site2).
When I tried the stat
command, it states Birth: -
.
So how can I find the creation time of a file?
filesystem metadata stat
edited Nov 27 '17 at 15:35
muru
1
1
asked May 21 '14 at 14:16
![](https://i.stack.imgur.com/o9mLm.jpg?s=32&g=1)
![](https://i.stack.imgur.com/o9mLm.jpg?s=32&g=1)
nux
21.3k2986113
21.3k2986113
1
Keep in mind that the 'creation time' of a file is not guaranteed to be accurate. There are many ways to 'fudge' the creation dates on a file.
â Thomas Wardâ¦
Nov 27 '17 at 15:00
add a comment |Â
1
Keep in mind that the 'creation time' of a file is not guaranteed to be accurate. There are many ways to 'fudge' the creation dates on a file.
â Thomas Wardâ¦
Nov 27 '17 at 15:00
1
1
Keep in mind that the 'creation time' of a file is not guaranteed to be accurate. There are many ways to 'fudge' the creation dates on a file.
â Thomas Wardâ¦
Nov 27 '17 at 15:00
Keep in mind that the 'creation time' of a file is not guaranteed to be accurate. There are many ways to 'fudge' the creation dates on a file.
â Thomas Wardâ¦
Nov 27 '17 at 15:00
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
56
down vote
accepted
There is a way to know the creation date of a directory , just follow these steps :
Know the inode of the directory by
ls -i
command (lets say for example its X)Know on which partition your directory is saved by
df -T /path
command ( lets say its on/dev/sda1
)Now use this command :
sudo debugfs -R 'stat <X>' /dev/sda1
You will see in the output :
crtime: 0x4e81cacc:966104fc -- mon Sep 27 14:38:28 2013
crtime is the creation date of your file .
What I tested :
- Created a directory at specific time .
- Accessed it .
Modified it by creating a file .
I tried the command and it gave an exact time .
- Then i modify it , and test again , the crtime remained the same ,
but modify and access time changed .
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
11
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.
â terdonâ¦
May 21 '14 at 15:31
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
add a comment |Â
up vote
51
down vote
@Nux found a great solution for this which you should all upvote. I decided to write a little function that can be used to run everything directly. Just add this to your ~/.bashrc
.
get_crtime()
grep -oP 'crtime.*--s*K.*')
printf "%st%sn" "$target" "$crtime"
done
Now, you can run get_crtime
to print the creation dates of as many files or directories as you like:
$ get_crtime foo foo/file
foo Wed May 21 17:11:08 2014
foo/file Wed May 21 17:11:27 2014
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen usingcp -p
or similar.
â terdonâ¦
Sep 29 '14 at 12:42
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
1
@demongolem yes, the CentOS version ofdf
doesn't seem to support the--output
option. In that case, you can replace that line withfs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.
â terdonâ¦
Feb 24 '16 at 18:52
 |Â
show 6 more comments
up vote
6
down vote
The inability of stat
to show the creation time is due to limitation of the stat(2)
system call, whose return struct didn't include a field for the creation time. Starting with Linux 4.11 (i.e., 17.10 and newer*), however, the new statx(2)
system call is available, which does include a creation time in its return struct.
* And possibly on older LTS releases using the hardware enablement stack (HWE) kernels. Check uname -r
to see if you are using a kernel at least at 4.11 to confirm.
Unfortunately, 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 hasn't yet added a wrapper for statx(2)
. 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.
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 more accessible:
- more filesystems should be supported than just the ext* ones (
debugfs
is a tool for ext2/3/4 filesystems, and unusable on others) - you don't need root to use this (except for installing some required packages, like
make
andlinux-libc-dev
).
Testing out an xfs system, for example:
$ truncate -s 1G temp; mkfs -t xfs temp; mkdir foo; sudo mount temp foo; sudo chown $USER foo
$ touch foo/bar
$ # some time later
$ echo > foo/bar
$ chmod og-w foo/bar
$ ./birth foo/bar | xargs -I date -d @
Mon Nov 27 14:43:21 UTC 2017
$ stat foo/bar
File: foo/bar
Size: 1 Blocks: 8 IO Block: 4096 regular file
Device: 700h/1792d Inode: 99 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ muru) Gid: ( 1000/ muru)
Access: 2017-11-27 14:43:32.845579010 +0000
Modify: 2017-11-27 14:44:38.809696644 +0000
Change: 2017-11-27 14:44:45.536112317 +0000
Birth: -
However, this didn't work for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.
If, or rather when, glibc adds 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. But I don't think this will be backported to LTS releases even if they do get newer kernels. So, I don't expect stat
on any current release (14.04, 16.04, 17.04, 17.10) to ever print the creation time without manual intervention.
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
add a comment |Â
up vote
3
down vote
TL;DR:
Just run:sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
(To figure out your fs, run df -T /path/to/your/file
, most likely it's going to be /dev/sda1
).
Long version:
We are going to run two commands:
Find out the name of partition name for your file.
df -T /path/to/your/file
The output is going to look like this (partition name is first):
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/<your fs> ext4 7251432 3481272 3509836 50% /Find out creation time for that file.
sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
In the output, look for
ctime
.
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
56
down vote
accepted
There is a way to know the creation date of a directory , just follow these steps :
Know the inode of the directory by
ls -i
command (lets say for example its X)Know on which partition your directory is saved by
df -T /path
command ( lets say its on/dev/sda1
)Now use this command :
sudo debugfs -R 'stat <X>' /dev/sda1
You will see in the output :
crtime: 0x4e81cacc:966104fc -- mon Sep 27 14:38:28 2013
crtime is the creation date of your file .
What I tested :
- Created a directory at specific time .
- Accessed it .
Modified it by creating a file .
I tried the command and it gave an exact time .
- Then i modify it , and test again , the crtime remained the same ,
but modify and access time changed .
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
11
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.
â terdonâ¦
May 21 '14 at 15:31
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
add a comment |Â
up vote
56
down vote
accepted
There is a way to know the creation date of a directory , just follow these steps :
Know the inode of the directory by
ls -i
command (lets say for example its X)Know on which partition your directory is saved by
df -T /path
command ( lets say its on/dev/sda1
)Now use this command :
sudo debugfs -R 'stat <X>' /dev/sda1
You will see in the output :
crtime: 0x4e81cacc:966104fc -- mon Sep 27 14:38:28 2013
crtime is the creation date of your file .
What I tested :
- Created a directory at specific time .
- Accessed it .
Modified it by creating a file .
I tried the command and it gave an exact time .
- Then i modify it , and test again , the crtime remained the same ,
but modify and access time changed .
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
11
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.
â terdonâ¦
May 21 '14 at 15:31
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
add a comment |Â
up vote
56
down vote
accepted
up vote
56
down vote
accepted
There is a way to know the creation date of a directory , just follow these steps :
Know the inode of the directory by
ls -i
command (lets say for example its X)Know on which partition your directory is saved by
df -T /path
command ( lets say its on/dev/sda1
)Now use this command :
sudo debugfs -R 'stat <X>' /dev/sda1
You will see in the output :
crtime: 0x4e81cacc:966104fc -- mon Sep 27 14:38:28 2013
crtime is the creation date of your file .
What I tested :
- Created a directory at specific time .
- Accessed it .
Modified it by creating a file .
I tried the command and it gave an exact time .
- Then i modify it , and test again , the crtime remained the same ,
but modify and access time changed .
There is a way to know the creation date of a directory , just follow these steps :
Know the inode of the directory by
ls -i
command (lets say for example its X)Know on which partition your directory is saved by
df -T /path
command ( lets say its on/dev/sda1
)Now use this command :
sudo debugfs -R 'stat <X>' /dev/sda1
You will see in the output :
crtime: 0x4e81cacc:966104fc -- mon Sep 27 14:38:28 2013
crtime is the creation date of your file .
What I tested :
- Created a directory at specific time .
- Accessed it .
Modified it by creating a file .
I tried the command and it gave an exact time .
- Then i modify it , and test again , the crtime remained the same ,
but modify and access time changed .
edited Jul 7 '14 at 14:51
answered May 21 '14 at 14:16
![](https://i.stack.imgur.com/o9mLm.jpg?s=32&g=1)
![](https://i.stack.imgur.com/o9mLm.jpg?s=32&g=1)
nux
21.3k2986113
21.3k2986113
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
11
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.
â terdonâ¦
May 21 '14 at 15:31
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
add a comment |Â
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
11
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.
â terdonâ¦
May 21 '14 at 15:31
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
I post this , because i like to discuss so i can understand better , i am wonder why people say that Linux doesn't support this feature
â nux
May 21 '14 at 15:21
11
11
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,
debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.â terdonâ¦
May 21 '14 at 15:31
Because Linux itself does not. The ext4 filesystem does have this information but the kernel does not provide an API to access it. Apparently,
debugfs
extracts it directly from the filesystem so it does not need to use the kernel's API. See here.â terdonâ¦
May 21 '14 at 15:31
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
I tested it. It worked perfectly on ext4 file system
â Fahim Babar Patel
Sep 21 '16 at 14:35
add a comment |Â
up vote
51
down vote
@Nux found a great solution for this which you should all upvote. I decided to write a little function that can be used to run everything directly. Just add this to your ~/.bashrc
.
get_crtime()
grep -oP 'crtime.*--s*K.*')
printf "%st%sn" "$target" "$crtime"
done
Now, you can run get_crtime
to print the creation dates of as many files or directories as you like:
$ get_crtime foo foo/file
foo Wed May 21 17:11:08 2014
foo/file Wed May 21 17:11:27 2014
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen usingcp -p
or similar.
â terdonâ¦
Sep 29 '14 at 12:42
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
1
@demongolem yes, the CentOS version ofdf
doesn't seem to support the--output
option. In that case, you can replace that line withfs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.
â terdonâ¦
Feb 24 '16 at 18:52
 |Â
show 6 more comments
up vote
51
down vote
@Nux found a great solution for this which you should all upvote. I decided to write a little function that can be used to run everything directly. Just add this to your ~/.bashrc
.
get_crtime()
grep -oP 'crtime.*--s*K.*')
printf "%st%sn" "$target" "$crtime"
done
Now, you can run get_crtime
to print the creation dates of as many files or directories as you like:
$ get_crtime foo foo/file
foo Wed May 21 17:11:08 2014
foo/file Wed May 21 17:11:27 2014
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen usingcp -p
or similar.
â terdonâ¦
Sep 29 '14 at 12:42
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
1
@demongolem yes, the CentOS version ofdf
doesn't seem to support the--output
option. In that case, you can replace that line withfs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.
â terdonâ¦
Feb 24 '16 at 18:52
 |Â
show 6 more comments
up vote
51
down vote
up vote
51
down vote
@Nux found a great solution for this which you should all upvote. I decided to write a little function that can be used to run everything directly. Just add this to your ~/.bashrc
.
get_crtime()
grep -oP 'crtime.*--s*K.*')
printf "%st%sn" "$target" "$crtime"
done
Now, you can run get_crtime
to print the creation dates of as many files or directories as you like:
$ get_crtime foo foo/file
foo Wed May 21 17:11:08 2014
foo/file Wed May 21 17:11:27 2014
@Nux found a great solution for this which you should all upvote. I decided to write a little function that can be used to run everything directly. Just add this to your ~/.bashrc
.
get_crtime()
grep -oP 'crtime.*--s*K.*')
printf "%st%sn" "$target" "$crtime"
done
Now, you can run get_crtime
to print the creation dates of as many files or directories as you like:
$ get_crtime foo foo/file
foo Wed May 21 17:11:08 2014
foo/file Wed May 21 17:11:27 2014
edited Nov 27 '17 at 13:07
answered May 21 '14 at 15:29
terdonâ¦
61.7k12125204
61.7k12125204
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen usingcp -p
or similar.
â terdonâ¦
Sep 29 '14 at 12:42
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
1
@demongolem yes, the CentOS version ofdf
doesn't seem to support the--output
option. In that case, you can replace that line withfs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.
â terdonâ¦
Feb 24 '16 at 18:52
 |Â
show 6 more comments
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen usingcp -p
or similar.
â terdonâ¦
Sep 29 '14 at 12:42
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
1
@demongolem yes, the CentOS version ofdf
doesn't seem to support the--output
option. In that case, you can replace that line withfs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.
â terdonâ¦
Feb 24 '16 at 18:52
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
Note that the creation date is not the creation date of the original file if the file is a copy (like it is with the modification date). Once a file is copied, the modification date is from the original, but the creation date is from the copy. (theres is some misunderstanding in this question: askubuntu.com/questions/529885/â¦)
â Jacob Vlijm
Sep 29 '14 at 10:57
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen using
cp -p
or similar.â terdonâ¦
Sep 29 '14 at 12:42
@JacobVlijm well, yes, of course. Isn't that obvious? How could it be otherwise? A copy is a new file that just happens to have the same contents as another. The modification time also changes for a copy by the way. It is set to the moment the copy was created unless you explicitly choose for that not to happen using
cp -p
or similar.â terdonâ¦
Sep 29 '14 at 12:42
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Absolutely, but it at the same time, it wouldn't be that unlogical if, like the mod. date, somewhere in the file the date would be stored when it originated. I must admit I didn't know that was not the case until I answered the linked question.
â Jacob Vlijm
Sep 29 '14 at 12:45
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
Just tried by the way, I just copied files in nautilus, modification date stays as it is (was), m. date is earlier than creation date.
â Jacob Vlijm
Sep 29 '14 at 13:42
1
1
@demongolem yes, the CentOS version of
df
doesn't seem to support the --output
option. In that case, you can replace that line with fs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.â terdonâ¦
Feb 24 '16 at 18:52
@demongolem yes, the CentOS version of
df
doesn't seem to support the --output
option. In that case, you can replace that line with fs=$(df foo | awk 'a=$1ENDprint a'
and the function will work as well. All I'm showing in this answer is a way to wrap the command from the accepted answer in a way that can be run directly for file/directory targets.â terdonâ¦
Feb 24 '16 at 18:52
 |Â
show 6 more comments
up vote
6
down vote
The inability of stat
to show the creation time is due to limitation of the stat(2)
system call, whose return struct didn't include a field for the creation time. Starting with Linux 4.11 (i.e., 17.10 and newer*), however, the new statx(2)
system call is available, which does include a creation time in its return struct.
* And possibly on older LTS releases using the hardware enablement stack (HWE) kernels. Check uname -r
to see if you are using a kernel at least at 4.11 to confirm.
Unfortunately, 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 hasn't yet added a wrapper for statx(2)
. 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.
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 more accessible:
- more filesystems should be supported than just the ext* ones (
debugfs
is a tool for ext2/3/4 filesystems, and unusable on others) - you don't need root to use this (except for installing some required packages, like
make
andlinux-libc-dev
).
Testing out an xfs system, for example:
$ truncate -s 1G temp; mkfs -t xfs temp; mkdir foo; sudo mount temp foo; sudo chown $USER foo
$ touch foo/bar
$ # some time later
$ echo > foo/bar
$ chmod og-w foo/bar
$ ./birth foo/bar | xargs -I date -d @
Mon Nov 27 14:43:21 UTC 2017
$ stat foo/bar
File: foo/bar
Size: 1 Blocks: 8 IO Block: 4096 regular file
Device: 700h/1792d Inode: 99 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ muru) Gid: ( 1000/ muru)
Access: 2017-11-27 14:43:32.845579010 +0000
Modify: 2017-11-27 14:44:38.809696644 +0000
Change: 2017-11-27 14:44:45.536112317 +0000
Birth: -
However, this didn't work for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.
If, or rather when, glibc adds 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. But I don't think this will be backported to LTS releases even if they do get newer kernels. So, I don't expect stat
on any current release (14.04, 16.04, 17.04, 17.10) to ever print the creation time without manual intervention.
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
add a comment |Â
up vote
6
down vote
The inability of stat
to show the creation time is due to limitation of the stat(2)
system call, whose return struct didn't include a field for the creation time. Starting with Linux 4.11 (i.e., 17.10 and newer*), however, the new statx(2)
system call is available, which does include a creation time in its return struct.
* And possibly on older LTS releases using the hardware enablement stack (HWE) kernels. Check uname -r
to see if you are using a kernel at least at 4.11 to confirm.
Unfortunately, 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 hasn't yet added a wrapper for statx(2)
. 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.
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 more accessible:
- more filesystems should be supported than just the ext* ones (
debugfs
is a tool for ext2/3/4 filesystems, and unusable on others) - you don't need root to use this (except for installing some required packages, like
make
andlinux-libc-dev
).
Testing out an xfs system, for example:
$ truncate -s 1G temp; mkfs -t xfs temp; mkdir foo; sudo mount temp foo; sudo chown $USER foo
$ touch foo/bar
$ # some time later
$ echo > foo/bar
$ chmod og-w foo/bar
$ ./birth foo/bar | xargs -I date -d @
Mon Nov 27 14:43:21 UTC 2017
$ stat foo/bar
File: foo/bar
Size: 1 Blocks: 8 IO Block: 4096 regular file
Device: 700h/1792d Inode: 99 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ muru) Gid: ( 1000/ muru)
Access: 2017-11-27 14:43:32.845579010 +0000
Modify: 2017-11-27 14:44:38.809696644 +0000
Change: 2017-11-27 14:44:45.536112317 +0000
Birth: -
However, this didn't work for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.
If, or rather when, glibc adds 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. But I don't think this will be backported to LTS releases even if they do get newer kernels. So, I don't expect stat
on any current release (14.04, 16.04, 17.04, 17.10) to ever print the creation time without manual intervention.
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
add a comment |Â
up vote
6
down vote
up vote
6
down vote
The inability of stat
to show the creation time is due to limitation of the stat(2)
system call, whose return struct didn't include a field for the creation time. Starting with Linux 4.11 (i.e., 17.10 and newer*), however, the new statx(2)
system call is available, which does include a creation time in its return struct.
* And possibly on older LTS releases using the hardware enablement stack (HWE) kernels. Check uname -r
to see if you are using a kernel at least at 4.11 to confirm.
Unfortunately, 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 hasn't yet added a wrapper for statx(2)
. 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.
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 more accessible:
- more filesystems should be supported than just the ext* ones (
debugfs
is a tool for ext2/3/4 filesystems, and unusable on others) - you don't need root to use this (except for installing some required packages, like
make
andlinux-libc-dev
).
Testing out an xfs system, for example:
$ truncate -s 1G temp; mkfs -t xfs temp; mkdir foo; sudo mount temp foo; sudo chown $USER foo
$ touch foo/bar
$ # some time later
$ echo > foo/bar
$ chmod og-w foo/bar
$ ./birth foo/bar | xargs -I date -d @
Mon Nov 27 14:43:21 UTC 2017
$ stat foo/bar
File: foo/bar
Size: 1 Blocks: 8 IO Block: 4096 regular file
Device: 700h/1792d Inode: 99 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ muru) Gid: ( 1000/ muru)
Access: 2017-11-27 14:43:32.845579010 +0000
Modify: 2017-11-27 14:44:38.809696644 +0000
Change: 2017-11-27 14:44:45.536112317 +0000
Birth: -
However, this didn't work for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.
If, or rather when, glibc adds 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. But I don't think this will be backported to LTS releases even if they do get newer kernels. So, I don't expect stat
on any current release (14.04, 16.04, 17.04, 17.10) to ever print the creation time without manual intervention.
The inability of stat
to show the creation time is due to limitation of the stat(2)
system call, whose return struct didn't include a field for the creation time. Starting with Linux 4.11 (i.e., 17.10 and newer*), however, the new statx(2)
system call is available, which does include a creation time in its return struct.
* And possibly on older LTS releases using the hardware enablement stack (HWE) kernels. Check uname -r
to see if you are using a kernel at least at 4.11 to confirm.
Unfortunately, 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 hasn't yet added a wrapper for statx(2)
. 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.
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 more accessible:
- more filesystems should be supported than just the ext* ones (
debugfs
is a tool for ext2/3/4 filesystems, and unusable on others) - you don't need root to use this (except for installing some required packages, like
make
andlinux-libc-dev
).
Testing out an xfs system, for example:
$ truncate -s 1G temp; mkfs -t xfs temp; mkdir foo; sudo mount temp foo; sudo chown $USER foo
$ touch foo/bar
$ # some time later
$ echo > foo/bar
$ chmod og-w foo/bar
$ ./birth foo/bar | xargs -I date -d @
Mon Nov 27 14:43:21 UTC 2017
$ stat foo/bar
File: foo/bar
Size: 1 Blocks: 8 IO Block: 4096 regular file
Device: 700h/1792d Inode: 99 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ muru) Gid: ( 1000/ muru)
Access: 2017-11-27 14:43:32.845579010 +0000
Modify: 2017-11-27 14:44:38.809696644 +0000
Change: 2017-11-27 14:44:45.536112317 +0000
Birth: -
However, this didn't work for NTFS and exfat. I guess the FUSE filesystems for those didn't include the creation time.
If, or rather when, glibc adds 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. But I don't think this will be backported to LTS releases even if they do get newer kernels. So, I don't expect stat
on any current release (14.04, 16.04, 17.04, 17.10) to ever print the creation time without manual intervention.
edited Nov 28 '17 at 2:53
answered Nov 27 '17 at 14:52
muru
1
1
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
add a comment |Â
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
Thanks for linking to github. I searched a few months ago when 4.11 came out and didn't find anything and then forgot about it.
â WinEunuuchs2Unix
Nov 28 '17 at 0:34
add a comment |Â
up vote
3
down vote
TL;DR:
Just run:sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
(To figure out your fs, run df -T /path/to/your/file
, most likely it's going to be /dev/sda1
).
Long version:
We are going to run two commands:
Find out the name of partition name for your file.
df -T /path/to/your/file
The output is going to look like this (partition name is first):
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/<your fs> ext4 7251432 3481272 3509836 50% /Find out creation time for that file.
sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
In the output, look for
ctime
.
add a comment |Â
up vote
3
down vote
TL;DR:
Just run:sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
(To figure out your fs, run df -T /path/to/your/file
, most likely it's going to be /dev/sda1
).
Long version:
We are going to run two commands:
Find out the name of partition name for your file.
df -T /path/to/your/file
The output is going to look like this (partition name is first):
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/<your fs> ext4 7251432 3481272 3509836 50% /Find out creation time for that file.
sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
In the output, look for
ctime
.
add a comment |Â
up vote
3
down vote
up vote
3
down vote
TL;DR:
Just run:sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
(To figure out your fs, run df -T /path/to/your/file
, most likely it's going to be /dev/sda1
).
Long version:
We are going to run two commands:
Find out the name of partition name for your file.
df -T /path/to/your/file
The output is going to look like this (partition name is first):
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/<your fs> ext4 7251432 3481272 3509836 50% /Find out creation time for that file.
sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
In the output, look for
ctime
.
TL;DR:
Just run:sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
(To figure out your fs, run df -T /path/to/your/file
, most likely it's going to be /dev/sda1
).
Long version:
We are going to run two commands:
Find out the name of partition name for your file.
df -T /path/to/your/file
The output is going to look like this (partition name is first):
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/<your fs> ext4 7251432 3481272 3509836 50% /Find out creation time for that file.
sudo debugfs -R 'stat /path/to/your/file' /dev/<your fs>
In the output, look for
ctime
.
edited Nov 13 '17 at 3:23
![](https://i.stack.imgur.com/eVuAv.png?s=32&g=1)
![](https://i.stack.imgur.com/eVuAv.png?s=32&g=1)
wjandrea
7,14242155
7,14242155
answered Jan 14 '16 at 20:19
Lukasz Czerwinski
1335
1335
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f470134%2fhow-do-i-find-the-creation-time-of-a-file%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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
1
Keep in mind that the 'creation time' of a file is not guaranteed to be accurate. There are many ways to 'fudge' the creation dates on a file.
â Thomas Wardâ¦
Nov 27 '17 at 15:00