D7423: [WIP/assistance needed] Populate UDS_CREATION_TIME on Linux if statx system call is available

Fabian Vogt noreply at phabricator.kde.org
Fri Aug 17 08:29:13 BST 2018


fvogt requested changes to this revision.
fvogt added a comment.
This revision now requires changes to proceed.


  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`.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D7423

To: ngraham, dfaure, broulik, elvisangelaccio, #frameworks, #dolphin, fvogt
Cc: fvogt, kde-frameworks-devel, bruns, meven, ltoscano, #frameworks, michaelh, ngraham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180817/b8f62b6f/attachment.htm>


More information about the kfm-devel mailing list