From 0e440f3b7eda4c66eda6c4a6c87e54c7f5ccb7f6 Mon Sep 17 00:00:00 2001
From: Christian Kamm <mail@ckamm.de>
Date: Tue, 11 Jun 2019 15:27:33 +0200
Subject: [PATCH 1/2] SuffixVfs: Simplify logs by avoiding EVAL_RENAME for
 downloads

When a file is tagged ItemTypeVirtualFileDownload in the database the
REMOTE pass in csync_update would not find the matching item in the
database. It worked anyway since the rename detection finds it, sees
the type tag and does the right thing. But the logging was confusing.

This change allows the pass to find the matching entry in the database
and proceed to the "db-entry-found" case without going through rename
detection.
---
 src/csync/csync_update.cpp | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/csync/csync_update.cpp b/src/csync/csync_update.cpp
index df17ca63cc..90527b3b0f 100644
--- a/src/csync/csync_update.cpp
+++ b/src/csync/csync_update.cpp
@@ -197,11 +197,15 @@ static int _csync_detect_update(CSYNC *ctx, std::unique_ptr<csync_file_stat_t> f
       auto virtualFilePath = fs->path;
       virtualFilePath.append(ctx->virtual_file_suffix);
       ctx->statedb->getFileRecord(virtualFilePath, &base);
-      if (base.isValid() && base._type == ItemTypeVirtualFile) {
-          fs->type = ItemTypeVirtualFile;
-          fs->path = virtualFilePath;
-      } else {
-          base = OCC::SyncJournalFileRecord();
+      if (base.isValid()) {
+          if (base._type == ItemTypeVirtualFile) {
+              fs->type = ItemTypeVirtualFile;
+              fs->path = virtualFilePath;
+          } else if (base._type == ItemTypeVirtualFileDownload) {
+              // keep everything: fs looks like a remote file
+          } else {
+              base = OCC::SyncJournalFileRecord();
+          }
       }
   }
 

From d5ab19ebf3ddf486ce58ff3ab712c5b4cdade45d Mon Sep 17 00:00:00 2001
From: Christian Kamm <mail@ckamm.de>
Date: Wed, 5 Jun 2019 14:50:46 +0200
Subject: [PATCH 2/2] Upload: Catch out-of-memory error #6880

This will avoid a rare-but-regular crash in low-memory situations.

Note that this is a workaround: In 2.6 this code should be adjusted to
not read a full file chunk into memory immediately and instead load more
data on demand.
---
 src/libsync/propagateupload.cpp | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/libsync/propagateupload.cpp b/src/libsync/propagateupload.cpp
index a8b260515c..e21eb70286 100644
--- a/src/libsync/propagateupload.cpp
+++ b/src/libsync/propagateupload.cpp
@@ -341,7 +341,12 @@ bool UploadDevice::prepareAndOpen(const QString &fileName, qint64 start, qint64
     }
 
     size = qBound(0ll, size, FileSystem::getSize(fileName) - start);
-    _data.resize(size);
+    try {
+        _data.resize(size);
+    } catch (const std::bad_alloc &) {
+        setErrorString(tr("Not enough memory to allocate file buffer of size %1").arg(size));
+        return false;
+    }
     auto read = file.read(_data.data(), size);
     if (read != size) {
         setErrorString(file.errorString());