The original content is moved to a backup, then the new file is moved
into its place. If that second step fails, we have to at least try
to move the backup back into the original place, and definitely
not remove the backup.
This behavior changed in 0dafe5cb8c
Task-number: QTCREATORBUG-21724
Change-Id: I996098576c0ceed59dd7359ac4f1b9d33f87d596
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
If we can not delete a file via the ReplaceFile operation, because we ca
not get the DELETE access right we still can try to replace it contents.
Task-number: QTCREATORBUG-7668
Change-Id: I8804133a0e118518307f33976b821d5b2fdc9b8d
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Many issues, mostly in headers, were not addressed in
e38410b76c
modernize-use-auto
modernize-use-nullptr
modernize-use-override
modernize-use-using
modernize-use-default-member-init
modernize-use-equals-default
Change-Id: I320a51726db881e582b898948d53735ebb06887a
Reviewed-by: hjk <hjk@qt.io>
It breaks cross-compilation on linux/mingw.
This reverts commit 1c014ed3d9.
Change-Id: I3e8183ec318541a4393ad242eefbdeaa78b7be44
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Although Windows is case insensitive, and lower case always works, Clang
complains:
Lexical or Preprocessor Issue: warning: non-portable path to file
'<FooBar.h>'; specified path differs in case from file name on disk
Change-Id: I8f94e9fb62f6afec8aa6b9d08a7c78f6ba8a4435
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
In these cases the user might not have sufficient rights for
ReplaceFile to merge all file attributes and ACLs.
Make ReplaceFile ignore these errors.
Task-number: QTCREATORBUG-20560
Change-Id: I6980d8af66cb7200c39726f0e7273df83c99bf5c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Previous fix accidently broke saving files that do not
exist yet. They need to call rename instead of ReplaceFile.
Change-Id: Ida47845a59c1f2fe26a39dc593ab0f83fae9d18b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
...fixes file saving on Windows in specific circumstances.
File deletion on Windows is quite tricky. If you simply
remove the file opened by another app that shares it for
deletion the file might become semi-removed. It looks
like it still exists but it is in fact inaccessible for
any operations until the other app frees the handle.
To solve that case there is a ReplaceFile API call
which carefully deals with that case.
[Backstory] Oswald Buddenhagen insists that this fix is
rather a workaround and we should solve file access
problem in llvm.
For that purpose we have QTCREATORBUG-19404 and upstream
https://bugs.llvm.org/show_bug.cgi?id=35558
Task-number: QTCREATORBUG-15449
Change-Id: If37d484231b79d8e33822c795232dc31243c88c0
Reviewed-by: David Schulz <david.schulz@qt.io>
When we derive from QTemporaryFile we can't unlock file
to be used by outer functions.
With this change lock is managed by m_tempFile variable and
can be released by reseting m_tempFile.
Change-Id: I41339410471c69d1e73df49f04bc2d5c2036a064
Reviewed-by: David Schulz <david.schulz@qt.io>
Remove temporary files left after fail.
Set error string for locked file.
Task-number: QTCREATORBUG-15449
Change-Id: Ibc8b01a4ea47870c29493a69718db929070ac13f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When a new file was created from the file menu, the permissions
on *nix was always 0600 regardless of the proess' current umask.
Fixed by letting CorePlugin::initialize() initialize the umask in
Utils::SaveFile. Since getting the system's umask is not thread
safe this can't be done directly in SaveFile::open.
Task-number: QTCREATORBUG-6513
Change-Id: I10d8b2f4ab85574ed3004b5e646664c2255196b9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
this ensures that creator doesn't eat my config files on every crash.
Change-Id: I18f8135158e17d064774a49fe170b63c89517e49
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
