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

[David Faure]

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


  In D25010#565502 <https://phabricator.kde.org/D25010#565502>, @meven wrote:
  
  > 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.
  
  
  But this isn't only about configuring the statx call. If we are not interested in the name, we save the QFile::decodeName() call (8 bit to 16 bit conversion, triggering also a memory allocation).
  
  > 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.
  
  Right -- at some point we should also use the details stuff in other ioslaves :-)
  
  > 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.
  
  Interesting, but given that statx isn't always available, I fear this will make the code quite complex?
  
  > 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.
  
  I need to think more about this, gotta go.

INLINE COMMENTS

> kossebau wrote in directorysizejob.cpp:137
> More correct would be KIOCORE_BUILD_DEPRECATED_SINCE(5, 65)., not ENABLE here and in the other cpp files.

Now that I look at this again, we do NOT want to follow symlinks here.

This was a bug in the existing code.

In Dolphin we want to display the size of the target file (more useful information than the size of the symlink itself), but when calculating directory size, we do NOT want to follow the symlink, the target size does not count.

These new flags allow to fix this long-standing bug.

REPOSITORY
  R241 KIO

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/20191122/41282862/attachment.html>