D25010: [StatJob] Use A QFlag to specify the details returned by StatJob

Méven Car noreply at phabricator.kde.org
Thu Nov 21 08:48:25 GMT 2019


meven added a comment.


  In D25010#565421 <https://phabricator.kde.org/D25010#565421>, @dfaure wrote:
  
  > Hmm, I meant Name is always useful when *listing*. But when *stating*, we don't always need to get the name back. The NoDetails comment is about a stat that really can just succeed/fail.
  
  
  I added
  
    enum StatDetail {
        /// No field returned, useful to check if a file exists
        NoDetails = 0x0,
  
  Funny thing is that statx includes always the name, down to syscall we can save at most STATX_SIZE , STATX_TYPE fields in NoDetails case.
  I updated kdiroperator.cpp to use it line 748 since it only checks if a file exists.
  This code path is not run for local files anyway.
  
  > We can always add NoDetails later (with a value of 0), however, so I'll stop nitpicking here :-)
  
  I would not mind nitpicking/discussing a little more, this is easier to do now and since it is no small change.
  As long as we don't go off topic at least now I have a design standpoint validation.
  
  Another thing comes to mind
  If we allow not to fill KIO::UDSEntry::UDS_LINK_DEST but when KIO::ResolveSymlink is passed, we can save the second STAT by not passing AT_SYMLINK_NOFOLLOW to the first statx.
  So perhaps we want to expose a detail for this use case : that is add a IncludeLinkDest to KIO::StatDetail removing this field for StatDetail::Basic.
  I am not sure we have any use case currently though.

INLINE COMMENTS

> dfaure wrote in statjob.h:236
> missing the same #if as the above methods, no?
> In a "clean" build it should disappear.

It shares the same #if block with the stat function

REPOSITORY
  R241 KIO

BRANCH
  arcpatch-D25010

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

To: meven, #frameworks, dfaure, kossebau
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191121/d25af67f/attachment.html>


More information about the Kde-frameworks-devel mailing list