QSaveFile results in loss of extended file attributes

QSaveFile, while advertizing itself for writing "without losing existing data if the writing operation fails", sadly loses existing data when the writing operation succeeds: the ownership of the file is changed to the system user and group of the current process (on linux) and any extended file attributes are dropped (unless direct write happens).

How to reproduce:

Prepare test file test.txt, making it owned by another system user in a special group (not users) shared with your own account

touch test.txt
# allow write access to the group
chmod g+w test.txt
# make file owned by another system user and by some special group (not "users") which the current user and other user are both in
sudo chown otheruser:specialgroup test.txt
# add some extended file attribut
setfattr -n user.comment -v "foo" test.txt

See metadata:

ls -l test.txt
getfattr -n user.comment test.txt

Compile and run:

qmake-qt5 && make
./qsavefile

See how metadata is lost/changed:

ls -l test.txt
getfattr -n user.comment test.txt

A fix to not lose the extended file attributes might be to copy them over to the temporary file, no idea if that works for all systems and all data, I only hope it does.
The file ownership seems to be more tricky, if not unsolvable. Perhaps there could be another flag/mode like "useDirectWriteForNotOwnedFiles" (example name only), so the consumers of QSaveFile could tell if the value transaction support also over changed file ownership or not.

At least both issues should be documented in the API dox of QSaveFile (including the lack of support for hard links). This behaviour comes as painful surprise to your naive developer :/ Too bad in 2016 filesystems still seem do not have any proper native support for transactional updates and such hard-to-get-right hacks are needed.