Priority: P3: Somewhat important
Affects Version/s: 5.6.1
Fix Version/s: None
Component/s: Core: I/O
Environment:openSUSE Tumbleweed (Linux)
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
Compile and run:
See how metadata is lost/changed:
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.