File Creation Time

How to get file creation date/time in Bash/Debian?

Unfortunately your quest won't be possible in general, as there are only 3 distinct time values stored for each of your files as defined by the POSIX standard (see Base Definitions section 4.8 File Times Update)

Each file has three distinct associated timestamps: the time of last
data access, the time of last data modification, and the time the file
status last changed. These values are returned in the file
characteristics structure struct stat, as described in <sys/stat.h>.

EDIT: As mentioned in the comments below, depending on the filesystem used metadata may contain file creation date. Note however storage of information like that is non standard. Depending on it may lead to portability problems moving to another filesystem, in case the one actually used somehow stores it anyways.

Does Git store the file creation time?

They can see the time when a file was added to the repository, via the commit date.

They cannot see the "file creation" or "file modification" timestamps of the file in your local filesystem.

Example

$ git init
Initialized empty Git repository in /tmp/tmp.t4KdOYhQGr/.git/
$ echo bla >file.txt
$ git add file.txt
$ git commit -m 'Added a file'
[master (root-commit) 26b458c] Added a file
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt

Let's look at the commit object:

$ git cat-file -p 26b458c
tree 80717c30ff0d58d079079d2f4d38441035093c49
author mkrieger1 <me@example.email> 1590570496 +0200
committer mkrieger1 <me@example.email> 1590570496 +0200

Added a file

It contains:

• A reference to a tree object
• An author with name, email, and timestamp
• A committer with name, email, and timestamp

These timestamps specify when a commit was first authored, and when it was committed (can be different, e.g. in case of cherry-picking, but here it's the same).

Let's look at the tree object referenced by the commit:

$ git cat-file -p 80717c30ff0d58d079079d2f4d38441035093c49
100644 blob a7f8d9e5dcf3a68fdd2bfb727cde12029875260b    file.txt

It contains a list of blob objects (only a single one in this case), with for each:

• File permissions
• A reference to the blob data
• The name of the blob in the tree

It doesn't contain any timestamps at all. Let's look at the blob object referenced by the tree:

$ git cat-file -p a7f8d9e5dcf3a68fdd2bfb727cde12029875260b
bla

It's just the bare file contents, no timestamps here, either.

Conclusion

The only timestamps that are stored in a Git repository are the "author" and "committer" dates in the commit objects. The tree and blob objects do not contain any timestamps.

There is no timestamp information about the files in the local filesystem contained in the Git repository.

How to find the Creation time of a .wav file using C++

The Timestamp field in the WAV file metadata and the file creation date are to unrelated pieces of information.

The file creation date is the date the file was created on the hard drive. You can use the Windows API GetFileTime to get the creation, last access and last write times.

The Timestamp is just some information someone put inside the WAV file. It may or may not be present and may or may not be the same time/date information you will get with GetFileTime.

How to find file creation date in Windows using Go

The FileInfo.Sys method returns the system specific data structures. On Windows, this will be a syscall.Win32FileAttributeData, which looks like

type Win32FileAttributeData struct {
    FileAttributes uint32
    CreationTime   Filetime
    LastAccessTime Filetime
    LastWriteTime  Filetime
    FileSizeHigh   uint32
    FileSizeLow    uint32
}

Getting the creation time would look something like:

d := fi.Sys().(*syscall.Win32FileAttributeData)
cTime = time.Unix(0, d.CreationTime.Nanoseconds())

Since this is windows specific, this of course should be protected by build constraints. Either using a _windows.go file or // +build windows

File creation date for copied files java nio

I see the same behavior on Windows 10 using OpenJDK 13. Although you mention the creation time is correct in File Explorer but not when queried via Java. My experience is different; File Explorer shows the correct (i.e. preserved) last modified time but, when I open up the properties dialog for the copy, the creation time is set to when the file was copied.

Note that while not preserving the creation time may be undesirable, I'm not sure this would be considered a bug in Java. The documentation of Files#copy(Path,Path,CopyOption...) says:

Attempts to copy the file attributes associated with this file to the target file. The exact file attributes that are copied is platform and file system dependent and therefore unspecified. Minimally, the last-modified-time is copied to the target file if supported by both the source and target file stores. Copying of file timestamps may result in precision loss.

^{- From the description of COPY_ATTRIBUTES in the options table.}

As you can see, minimally only the last modified time will be copied and even that is not necessarily guaranteed. This also indicates the problem could be platform-specific; if Windows, or at least the Windows API used by Java, doesn't support preserving the creation time then what you're seeing is expected behavior. But if you believe the behavior is a bug you can always submit a bug report. Before you do, however, make sure a report doesn't already exist, including ones which have been resolved as, for instance, "won't fix".

Note: The above paragraph focuses on Windows. Unfortunately, I don't have access to other operating systems at the moment, so I can't test if those other operating systems have the same problem. You never explicitly mention that you're using Windows, though I assume you are based on the path in your question (i.e. "C:\\Users\\...") and your use of the word "explorer".

That said, I believe a workaround may be possible: Copy the creation time yourself after copying the directory or file:

Files.copy(source, target, options); // 'options' should include COPY_ATTRIBUTES
Files.setAttribute(target, "creationTime", Files.getAttribute(source, "creationTime"));

The reason the comment says COPY_ATTRIBUTES should be be included is because, as documented, the option may result in any number of attributes being copied, even if the creation time is not one of them. Of course, if you'd like to make sure the last modified and access times are also copied, you can modify the above into:

Files.copy(source, target, options); // 'options' should include COPY_ATTRIBUTES

BasicFileAttributes srcAttrs = Files.readAttributes(source, BasicFileAttributes.class);
BasicFileAttributeView tgtView = Files.getFileAttributeView(target, BasicFileAttributeView.class);

tgtView.setTimes(srcAttrs.lastModifiedTime(), srcAttrs.lastAccessTime(), srcAttrs.creationTime());

May be interesting to note that Files#copy(Path,Path,CopyOption...) does something very similar to the second example, but only if the source and target have the different FileSystemProvider instances. Otherwise, the method delegates to the shared FileSystemProvider, which is different for each implementation.

---

Related Topics