In D17816#671870, @arrowd wrote:

I decided to help with this a bit.

My hands are full at the moment, so I'm unable to finish this for some time. Thank you.

Are you talking about someting like this, @bruns? 512 bytes would be a good buffer size?
Not sure if prealocatting the buffers would be better than making syscals.

qCDebug -> qCWarning

Hi, @usta and @bruns
We still have some change pending?
Thanks.

typo

Camel case

done

missed cast

Simplify.

Move away from strcpy =]

trailing space

Using a STL-style iterator for keyList and qstrcpy and qtrncpy to get each key value.
Small fixes

Tried to make a function to feed m_keyList on BSD, but the result was somewhat ugly.
I don't like to use buffers if I can have typed data, but libc uses buffers, so maybe I was putting the sqare piece on the circle hole.
So, accepted @bruns suggestion about the loop.

Small fixes.

Refactored the tests:

In D17816#627925, @pino wrote:

xattrs on the Linux tmpfs have been supported for many years, almost a decade.

In D17816#627918, @bruns wrote:

Not true in general ... please add back, and check if the destination FS supports XAttrs. If not, print a warning and SKIP

As @dfaure suggested, moved the attribute copy logic to a function on file_unix.cpp.

Many thanks to getting this live again, @tmarshall . A year ago my vacations ended and I can't get this ready to ship.

My vacancies ended and I'm making the annual planning for my classes, so I will be busy for at least two weeks, but I plan to work on the subjob bug as soon my schedule allows it.

Can we ship it, or using a subjob on KIO::copy is mandatory here?

I'm not sure why the tests fail, and the tests failing are unrelated to xattrs. I think there is some problem in queuing the subjobs and ensuring they all have finished.
After the copy job is finished, the copyLocalDirectory test can't find the file inside the copied test directory. Manually testing recursive copy I can't find problems, but the autotest fail. So, I think some parts of the copy job are executed after the copyjob finishes if I add a subjob.
As I said, we can use start, instead of exec, to be asynchronous, but using a subjob seems to need some refactor, maybe adding a new state for the xattr subjob.

Use subjobs on file_copy and other small fixes

For some reason the added kio was not included

All use cases working, added a new KIO to copy xattr

In D17816#386810, @funkybomber wrote:

On a related note, is it possible that the "QSaveFile" is also responsible for a similar behaviour in Ark?

small cleanup

Tests refactored, but no multiplatform. Other small fixes.

Tests added, includes and ifdefs reworked

In D17816#384056, @pino wrote:

• NULL -> nullptr
• there is not just glibc

I'm following the pattern in Baloo, that keeps NULL on Mac and *BSD. I don't have any of these systems to test, so I didn't touch it.
Didn't searched yet about compatibility of these functions on libc alternatives. Frameworks officially supports a subset of them I should check?

Bug resolved in a proper way with help of Tomaz Canabrava

As using qDebug supressed the error, I changed to qCWarning and managed to track the memory corruption. On my system, after getting the list of keys on source file, the local variable holding this file path gets corrupted. I'm using a code almost identical to official example [1], and enlarging the buffer, or allocating it on the heap didn't resoled the issue.
A hackish workaround is to not store the file path after conversion (const char*), and using QUrl.path().toLocal8Bit().data(); in all nine calls.
I'm not happy with this solution, but I think I reached my limit here. Commiting this hackish version for review, and going to make some tests.

Refactored to a function, works on all use cases. Data corruption remains

In D17816#383421, @davidedmundson wrote:

Why do we need the code in both CopyJob and File_unix?

There is one use case (copy of dirs with rename, due name conflict) where the patches not work, and I can't test on *BSD or Mac.

Support for preserving xattrs on dirs, bugfix

Tested coping from e to VFAT and btrfs.
Successfully copy/move to and from VFAT, losing the xattrs due to lack of support, but don't crash.
Successfully copy/move to and from btrfs, preserving xattrs.