tmarshall added inline comments. INLINE COMMENTS
> dfaure wrote in copyjob.cpp:1119 > That sounds racy; the subjob might not be finished by the time the main job > is finished, if you just "start and forget". > > I cannot accept this commit with an exec() in here. The easy and modern way > to make this async is just a connect and a lambda (which contains the rest of > the code here). > > I have to wonder though: do we have a fast way to determine whether we > actually need the additional subjob? (to avoid making this slower on systems > -- or files -- without xattr) > > Hmm, or a much bigger architectural question: why doesn't kio_file copy the > xattr as part of FileProtocol::copy(), as it already does with e.g. > permissions and ACLs, instead of doing this in a separate job? Please help me understand for a moment. I'm not the original author of this patch and am trying to bring it to completion. I just need to be caught up to speed. In reading this piece of code over, I wasn't entirely sure of the author's intent. It seems like he wants to create a new job which copies the xattrs and then run it asynchronously. Why is the exec call bad? What does a lambda do that the exec call does not? In terms of determining when the job is actually required, one could test to see if the file has xattrs or indeed if the system has xattrs support. We could surround the invokation of the xattrs copy job with an `#ifdef HAVE_SYS_XATTR_H`, for example. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D17816 To: tmarshall, dfaure, chinmoyr, bruns, #frameworks, cochise Cc: tmarshall, arrowd, cfeck, bruns, phidrho, dhaumann, funkybomber, abika, pino, davidedmundson, ngraham, atha.kane, spoorun, nicolasfella, kde-frameworks-devel, LeGast00n, GB_2, michaelh
