Is there really no way in Linux to get creation time for files on cifs/smb share?
Solution 1
The Linux kernel has had an xstat(2)
system call in the works for several years, now. David Howells of RedHat did much of the work. xstat(2)
allows one to retrieve the creation time (sometimes rechristened the "born time" or "birth time" in the Linux and BSD worlds for no really good reason) of files from the several filesystems that support it, including EXT4 (which has a creation timestamp on disc) and CIFS (which with its DOS/OS/2/Windows heritage has supported a creation timestamp as a first class citizen for decades). M. Howells worked on the CIFS patches that go along with the system call.
OpenSolaris and the BSDs actually do have a st_birthtim
datum in their stat(2)
system call right now, and the feature is accessible to script writers via application programs such as find
and ls
. On the OpenSolaris ls
man page you'll find crtime
alongside atime
, mtime
, and ctime
in several places. Similarly, the FreeBSD find
command has -Bmin
, -Bnewer
, and -Btime
primaries. And the Mac OS ls
has a -U
option.
If you were writing your script for OpenSolaris, the BSDs, or Mac OS 10, you could just get on with whatever you want to do with creation times right now. Indeed if you were writing for Windows you could do the same. Cygwin has supported st_birthtim
since 2007, making Win32's CreationTime
timestamp, which it has had since the first version of Windows NT and which Windows NT maintains on both NTFS and FAT volumes, available to Cygwin tools.
However, the same isn't true in the GNU Linux world. Creation time capability has yet to make it to GNU coreutils' ls
or to GNU findutils' find
. Indeed, it isn't even part of the mainstream Linux kernel yet. Part of the problem is that the xstat(2)
system call got bogged down in a diversion where people wanted to keep three timestamps, instead of have four as in the Windows NT kernel API, and dump ctime
to replace it with crtime
.
Linus Torvalds' response in 2010 was that "it's all totally useless and people can't even agree on a name" and "Let's wait five years".
In fact, as I suspect most people reading this will know, the world has been widely agreeing the name "creation time" since the 1980s and we've been waiting at least 25 years already. It's the name used in OS/2 1.0; it's the name used in VMS ODS-1; it's the name used in Windows NT 3.5; it's the name used in SMB; and it's the name used in the question. ☺
Further reading
- David Howells (2010-07-15). [PATCH 08/18] xstat: CIFS: Return extended attributes [ver #6]. Linux kernel mailing list.
- 2.4.7 FileBasicInformation. Windows SMB protocol. MSDN. Microsoft corporation.
- find(1) manual page. FreeBSD manual pages.
- stat(2) manual page. FreeBSD manual pages.
- ls(1) manual page. Darwin manual pages. Apple corporation.
- Corinna Vinschen (2007-03-26). _Re: Support for st_birthtime_. Cygwin mailing list.
- Linus Torvalds (2010-07-22). Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]. Linux kernel mailing list.
- A.3.1.3 File Headers. Files-11. OpenVMS Systems Documentation. HP.
Solution 2
I cannot really answer this question, but at least I can give you a hint: the book Implementing CIFS: The Common Internet File System by Christopher R. Hertel has these two very interesting pages:
They seem to indicate that it is possible to retrieve the info you are looking for.
Related videos on Youtube
kiwisan
Updated on September 18, 2022Comments
-
kiwisan over 1 year
I am embarrassingly far along in a bash backup script and have missed something major. I know that ext3 filesystems don't track creation date, but copying files within ext3 updates the changed time as seen via stat (which would work). However, when files are copied from one Windows server to another (whose mounts I have via smb/cifs), from my testing, changed time is not updated. I'm using find to do the searching on the cifs shares. Is there really no way to detect when a new file is created over a cifs share from Linux using "find"?
Also, I am very familiar with rsync, and in this circumstance rsync's limitations rule it out as an option. I was thinking I could use rsync for the searching and try to pipe the results to the action (gzip), but I think the subshells would be ridiculous. Could be wrong, of course. Any suggestions would be much appreciated. Can provide more detail, but from my research I don't think it's possible.
-
Admin over 10 yearsWhat does stat(1) (part of GNU coreutils, most likely installed in package coreutils for whatever distribution you're using) give you for access/change/modify times for a file residing inside the filesystem in question? That might give you some hints at least.
-
kiwisan over 10 years
Stat
provides access time, modify time, and change time. Copying a file within ext3 updates change time. Windows (NT) has created time, of course, which gets updated when a file is created via a copy. However, from JdeBP's answer below, GNU coretutils such asstat
,ls
, andfind
, have no way to detect or display newly created files on Windows machines over a cifs share. Thanks for your comment.
-
-
kiwisan over 10 yearsThank you for taking the time to answer so thoroughly, and for the further reading. One question: I thought that rsync relied upon
stat
calls. How does rsync accomplish this differently thanfind
orls
? -
Jeffrey Bosboom over 6 years
statx
was added in 4.11. The cifs filesystem also exposes creation time as a pseudo-xattr,user.cifs.creationtime
, whose value is a Win32 FILETIME (64 bits storing the number of 100-nanosecond intervals since January 1, 1601 UTC), though it can only be read, not set. -
mato about 3 years"Birth time" has been used for ages, it sounds okay and it starts with a letter B, which is useful as it can be shortened to btime which goes nicely with atime, ctime, mtime and thus there's no reason for longer crtime that is too similar to ctime. In the end it's just a matter of getting used to it and no big ideal either way.