在 Linux 上使用 Python 获取文件创建时间

Question

os.stat returns st_mtime and st_ctime attributes, the modification time is st_mtime and st_ctime "change time" on POSIX. is there any function that return the creation time of a file using python and under Linux?

Answer 1

You probably can't. :

 3.1) How do I find the creation time of a file? You can't - it isn't stored anywhere. Files have a last-modified time (shown by "ls -l"), a last-accessed time (shown by "ls -lu") and an inode change time (shown by "ls -lc"). The latter is often referred to as the "creation time" - even in some man pages - but that's wrong; it's also set by such operations as mv, ln, chmod, chown and chgrp. The man page for "stat(2)" discusses this.

Answer 2

try:

st_birthtime

It isnt' guaranteed to be available on all systems though. From the docs:

On some Unix systems (such as Linux), the following attributes may also be available: st_blocks (number of blocks allocated for file), st_blksize (filesystem blocksize), st_rdev (type of device if an inode device). st_flags (user defined flags for file).

On other Unix systems (such as FreeBSD), the following attributes may be available (but may be only filled out if root tries to use them): st_gen (file generation number), st_birthtime (time of file creation).

http://docs.python.org/2/library/os.html#os.stat

Answer 3

By lack of a good utility, I've created crtime .

pip install crtime

Then you can use it like:

sudo crtime ./

Would print:

1552938281  /home/pascal/crtime/.gitignore
1552938281  /home/pascal/crtime/README.md
1552938281  /home/pascal/crtime/crtime
1552938281  /home/pascal/crtime/deploy.py
1552938281  /home/pascal/crtime/setup.cfg
1552938281  /home/pascal/crtime/setup.py
1552938961  /home/pascal/crtime/crtime.egg-info
1552939447  /home/pascal/crtime/.git
1552939540  /home/pascal/crtime/build
1552939540  /home/pascal/crtime/dist

Note that for large directories it will be easily 1000x faster than xstat above, as this creates a temporary file and then executes stat calls for all files at once.

In python (don't forget you need to still call it with sudo on linux):

from crtime import get_crtimes, get_crtimes_in_dir
get_crtimes_in_dir("./")

Answer 4

According to a thread here OS X's HFS and Microsoft's NTFS also both track the birth time, and I'm told the OS X and Cygwin versions of stat() return this information. which looking at the osx stat manpage seems correct at least for mac:

a, m, c, B

The time file was last accessed or modified, of when the inode was last changed, or the birth time of the inode .

For linux newer filesystems like ext4, Btrfs and JFS do support this using debugfs , there is a bash function taken from here that will extract the date-created timestamp:

You may recover the file creation date if you deal with capable filesystem like EXT4 - journaling file system for Linux:

Improved timestamps

... Ext4 provides timestamps measured in nanoseconds. In addition, ext4 also adds support for date-created timestamps. But there no consensus in the community on that so

... as Theodore Ts'o points out, while it is easy to add an extra creation-date field in the inode (thus technically enabling support for date-created timestamps in ext4), it is more difficult to modify or add the necessary system calls, like stat() (which would probably require a new version) and the various libraries that depend on them (like glibc). These changes would require coordination of many projects. So even if ext4 developers implement initial support for creation-date timestamps, this feature will not be available to user programs for now. Which end up with the Linus final quote

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

xstat() {
  for target in "${@}"; do
    inode=$(ls -di "${target}" | cut -d ' ' -f 1)
    fs=$(df "${target}"  | tail -1 | awk '{print $1}')
    crtime=$(sudo debugfs -R 'stat <'"${inode}"'>' "${fs}" 2>/dev/null | 
    grep -oP 'crtime.*--\s*\K.*')
    printf "%s\t%s\n" "${crtime}" "${target}"
  done
}

Running it returns the creation date:

:~$ echo 'print("hello world")' > blah.py
:~$ xstat "blah.py"
Mon Jul  6 13:43:39 2015    blah.py
:~$ echo 'print("goodbye world")' > blah.py
:~$ xstat "blah.py"
Mon Jul  6 13:43:39 2015    blah.py

So unless the file system supports it then it is not possible, if the file system does then you could run the debugfs using subprocess and parse the output.

Answer 5

You might explain why you want to do this.

An indirect solution might be to use some revision control system (aka version control system = VCS) to manage the files whose birth time is needed.

So you could use git on such files (ie handle them as "source code"). Then you know not only when they have been created (in fact registered in the VCS using git add ), but why, by whom, what for, etc... Use git log to get all this...

Of course you somehow need to educate your users to use a VCS like git

Answer 6

Certain file systems do support recording the birth time, but Linux does not provide an interface for obtaining it.

See http://lwn.net/Articles/397442/

If one atempts to use the "stat" command to obtain it: % stat -c %w {file or dir}

The result will be a "-" due to it not having the ability to retrieving it. However, one can use this sample method utilizing debugfs with xstat to retrieve it (providing again, that the file system being used supports collecting it.)

https://gist.github.com/moiseevigor/8c496f632137605b322e

xstat() {
  for target in "${@}"; do
    inode=$(ls -di "${target}" | cut -d ' ' -f 1)
    fs=$(df "${target}"  | tail -1 | awk '{print $1}')
    crtime=$(sudo debugfs -R 'stat <'"${inode}"'>' "${fs}" 2>/dev/null | 
    grep -oP 'crtime.*--\s*\K.*')
    printf "%s\t%s\n" "${crtime}" "${target}"
  done
}

Note this requires sudo.

Answer 7

What do you mean it can't be done [1]? The function,

os.stat(path).st_birthtime

, works great.

\n[1]: \nSomebody said that it couldn't be done\n      But he with a chuckle replied\nThat “maybe it couldn't,” but he would be one\n      Who wouldn't say so till he'd tried.\nSo he buckled right in with the trace of a grin\n      On his face. If he worried he hid it.\nHe started to sing as he tackled the thing\n      That couldn't be done, and he did it!\n-- Edgar Albert Guest \n