2016-10-02 23:55:54 +01:00
|
|
|
#include "InstanceCreationTask.h"
|
|
|
|
|
|
2022-07-08 00:31:24 +01:00
|
|
|
#include <QDebug>
|
fix: move file deletion to the end of the instance update
This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
2022-08-06 01:26:02 +01:00
|
|
|
#include <QFile>
|
2016-10-02 23:55:54 +01:00
|
|
|
|
2022-07-31 22:21:59 +01:00
|
|
|
InstanceCreationTask::InstanceCreationTask() = default;
|
2016-10-02 23:55:54 +01:00
|
|
|
|
|
|
|
|
void InstanceCreationTask::executeTask()
|
|
|
|
|
{
|
2022-08-21 13:26:27 +01:00
|
|
|
setAbortable(true);
|
2022-08-06 01:25:21 +01:00
|
|
|
|
2022-07-31 22:21:59 +01:00
|
|
|
if (updateInstance()) {
|
|
|
|
|
emitSucceeded();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-08-01 00:29:12 +01:00
|
|
|
// When the user aborted in the update stage.
|
|
|
|
|
if (m_abort) {
|
|
|
|
|
emitAborted();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
fix: move file deletion to the end of the instance update
This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
2022-08-06 01:26:02 +01:00
|
|
|
if (!createInstance()) {
|
|
|
|
|
if (m_abort)
|
|
|
|
|
return;
|
2022-07-31 22:21:59 +01:00
|
|
|
|
fix: move file deletion to the end of the instance update
This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
2022-08-06 01:26:02 +01:00
|
|
|
qWarning() << "Instance creation failed!";
|
|
|
|
|
if (!m_error_message.isEmpty())
|
|
|
|
|
qWarning() << "Reason: " << m_error_message;
|
|
|
|
|
emitFailed(tr("Error while creating new instance."));
|
2022-07-08 00:31:24 +01:00
|
|
|
return;
|
2018-07-15 13:51:05 +01:00
|
|
|
}
|
2022-07-08 00:31:24 +01:00
|
|
|
|
fix: move file deletion to the end of the instance update
This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
2022-08-06 01:26:02 +01:00
|
|
|
// If this is set, it means we're updating an instance. So, we now need to remove the
|
|
|
|
|
// files scheduled to, and we'd better not let the user abort in the middle of it, since it'd
|
|
|
|
|
// put the instance in an invalid state.
|
|
|
|
|
if (shouldOverride()) {
|
2022-08-21 13:26:27 +01:00
|
|
|
setAbortable(false);
|
fix: move file deletion to the end of the instance update
This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
2022-08-06 01:26:02 +01:00
|
|
|
setStatus(tr("Removing old conflicting files..."));
|
|
|
|
|
qDebug() << "Removing old files";
|
|
|
|
|
|
|
|
|
|
for (auto path : m_files_to_remove) {
|
|
|
|
|
if (!QFile::exists(path))
|
|
|
|
|
continue;
|
|
|
|
|
qDebug() << "Removing" << path;
|
|
|
|
|
if (!QFile::remove(path)) {
|
|
|
|
|
qCritical() << "Couldn't remove the old conflicting files.";
|
|
|
|
|
emitFailed(tr("Failed to remove old conflicting files."));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
emitSucceeded();
|
|
|
|
|
return;
|
2016-10-02 23:55:54 +01:00
|
|
|
}
|