D17816: Support for xattrs on kio copy/move

[David Faure]

dfaure requested changes to this revision.
dfaure added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> jobtest.cpp:529
>  
> +QHash<QString, QString> getSampleAttrs()
> +{

prepend `static`

> jobtest.cpp:626
> +
> +QString getXattrCommand()
> +{

prepend `static`

> jobtest.cpp:638
> +        if (command.isEmpty()) {
> +            command = QStandardPaths::findExecutable("xattr");
> +        }

if (command.isEmpty())
      qWarning() << "ERROR: setfattr/setextattr/xattr not found";

to make it easier to debug than just this method returning empty.

> jobtest.cpp:650
> +    if (command.isEmpty() || command != "setfattr") {
> +        return;
> +    }

QSKIP("This test requires setfattr")

Otherwise it will look like a "PASS" in the test output.

> jobtest.cpp:753
> +    if (command.isEmpty() || command != "setfattr") {
> +        return;
> +    }

QSKIP

> tmarshall wrote in copyjob.cpp:1119
> Thanks to @ahmad78 for chatting with me about this in irc.
> 
> Everything works for me if I replace the `exec` call with a `start` call. Currently the result of the exec call is thrown away as the job itself does the error handling and there isn't much to do if the xattrs can't be copied for whatever reason.
> 
> As for why this is a different job, that was a design decision by the original author. It seems like a decent enough way forward to me as it leans on the side of modularity. The applications of xattrs are so broad that it's hard to say what they will be used for in the future or what the desired functionality might be. Having a separate job will allow for more flexibility regarding xattrs going forward.
> 
> In short, I don't really think it hurts to have a separate job and there is certainly the potential that it comes in handy.

I don't mind that errors don't propagate up here, that's fine, we certainly don't want the copy to fail if attributes can't be copied.

I do mind that this uses exec() (Qt eventloop re-entrancy is a nasty source of bugs), and I do mind a fire-and-forget subjob (if that's what start() here does -- unless the subjob gets registered?).

I have provided the solution already, connect the subjob's result to a lambda that contains the rest of the code in this method [but see below].

I just realized another problem: this is at the wrong layer. It should be in FileCopyJob, not in the high-level CopyJob (which lists directories, creates directories, etc. and delegates the task of copying one file to FileCopyJob). FileCopyJob is also used directly in many places (when a single file has to be copied) so if you want that to preserve xattr (rethorical question, I'm assuming you do) this should go down to FileCopyJob.

About this being a different job: actually, one doesn't prevent the other. Look at permissions. We have ChmodJob for setting permissions, but when FileCopyJob finds that the kioslave supports copy() (see DirectCopyJob on the app side) then copy() takes care of copying permissions too. FileCopyJob only calls ChmodJob for the special case of renaming and because the FileCopyJob API actually allows to change permissions, this doesn't apply to xattr.

When the kioslave doesn't support copy() and it falls back to "data pump" mode (get() + put()), FileCopyJob passes the permissions to the put() job. *That* is the case where it should follow that with a KIO::copy_xattr subjob, unless xattr can be passed by metadata to the put job?

I believe the same idea should be done for xattr (kio_file's copy() should copy xattr all by itself), to minimize roundtrips between the app and the slave. People complain that copying files with KIO is too slow, let's not make it worse.

> cfeck wrote in filecopyjob.cpp:519
> This waits (i.e. spawns a separate event loop) until the job is finished. Should use a subjob.

That's what should happen in copy() IMHO. But that's an optimization, I can accept that being done later.

And if you want to support other cases than file->file, like desktop, trash, smb, etc. then this should also be done when the put job finishes.

What's for sure is that doing it both in CopyJob and in FileCopyJob is overkill since the former uses the latter :-)

REPOSITORY
  R241 KIO

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

To: tmarshall, dfaure, chinmoyr, bruns, #frameworks, cochise
Cc: anthonyfieroni, tmarshall, arrowd, cfeck, bruns, phidrho, dhaumann, funkybomber, abika, pino, davidedmundson, ngraham, atha.kane, spoorun, nicolasfella, kde-frameworks-devel, LeGast00n, GB_2, michaelh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191231/135b81d1/attachment-0001.html>