Populate UDS_CREATION_TIME to make Dolphin display file creation times, if the supporting statx system call is available (in Linux Kernel 4.11 and later).
The commit log is inconsistent with the actual patch. It says "lack of a Qt version that supports this", but the patch doesn't use QFile at all, it uses statx. Either way, the patch can be tested, no?
This patch doesn't actually directly use statx(); it uses the existing approach, which goes through QFile, which is used to populate the statbuf object that we query. QT has gained support for populating the statbuf object using statx() in Linux where available in current git master, but that change hasn't landed in an actual released QT version yet.
If you can point me to a way to test this, I'll be happy to.
I can't comment on the content of the patch, but about the commit message, in order to close a bug, use the syntax:
while in order to add the commit as comment of a bug without closing it, use
Both keyword should be in a separate line.
Also, it's Qt, not QT.
Noted! Thanks, Luigi. I'd like to add BUG: 286689 to the commit message on a separate line. Does the title of this revision become the commit message? If so, how do I add another line? The text field doesn't seem to support multi-line strings.
The title of the revision becomes the first line; all the rest (summary, test, reviewers) become the rest of the content, a blank separator line is added automatically. Please add the BUG: line in the summary, not in the title.
Also, as the title becomes the first line, it would be nice to follow the usual git rules of length.
I haven't forgotten about this, but life has intervened and I'm not going to have time to work on it for a few days, maybe even a couple of weeks. If anyone else wants to run with it and take over, I won't be in the least bit offended. If not, I'll resume work at some point in the near to medium term future.
Unless I'm misunderstanding everything, birthTime_ is only set to a nonzero value as of https://github.com/qt/qtbase/commit/d3393ce25833c0afd7f0fa6b85fd6f3bd7ad520a#diff-e061e747264146cf47a86b371e512348R363, which only made it into Qt 5.10 and was not backported to 5.9.
I took a crack at accessing statx directly, but I'm waaaaaay out of my depth here and will need some help making this actually work. There doesn't seem to be a glibc wrapper for statx yet, so we have to access it directly, which is messy and I haven't figured out how to make it work yet, though I think I might be on the right track.
As such, this patch is presented--currently in non-working form, sadly--for discussion and hopefully instructional purposes. If someone else with more domain knowledge wants to grab this and do it right themselves, please feel free!
Problems that need to be overcome:
On neon it won't work as the kernel everything is built against (so the minimum API/ABI) is too old. You'll either have to hack around that by messing with include paths or use something more recent.
statx does not have a glibc wrapper, which means there is no statx(...) function. So HAVE_STATX is rightfully false.
What Qt does is different: If SYS_statx is defined, it determines during runtime whether the kernel supports it. QT_STATBUF is in any case a struct stat/stat64, so if your code calls statx, it'll corrupt memory.
The only reason your code even compiled is that stx_btime is not a macro, so that code wasn't compiled in.
There is a bigger design issue with this approach even: There are either "stx_" members or "st_" members available. So every access to "buff" needs to be guarded by both an #if HAVE_STATX and an if(statx_available).
You also need to note that the kernel syscall interface is different from glibc wrappers/posix functions: There is no errno, the error is directly in the return value.
So stat(...) == -1 is not equal to syscall(SYS_statx, ...) == -1. The latter is equivalent to stat(...) == -1 && errno == EPERM (EPERM is 1).
I suggest rewriting this to make use of a wrapper function instead of macros, like Qt does. You can find that in src/corelib/io/qfilesystemengine_unix.cpp.
This is no longer true with glibc 2.28, released two weeks ago. The interface is defined here:
So, first question which arises is, should we make it depend on glibc 2.28? There is no kernel dependency,
as glibc fills out the statx struct using other syscalls if statx is not available (of course, no birthtime then).