Fix edge case file upload bugs

[JC-comp]

Changes

• Wiat for download/upload threads to finish before closing databse: prevent invalid database access in threads causing segmentation fault
• Upload the file even if it already exists online: prevent skipping changes in local first mode
• Delete remote destination first for a local move if local destination not exists
• Add support for shared logger

[abraunegg]

@JC-comp
Could you please remove this commit: 7101210

Logging output is 100% broken at the moment for many things and is going to be 100% totally redone so it is better that this is not something you look at or add a commit for.

[abraunegg]

@JC-comp
Commit 0357f43 is now causing a conflict, please also pull this change from this PR

[JC-comp]

Not-yet-ready and patched commits have been removed

[abraunegg]

@JC-comp
Specifically for this commit (9426134), do you have an actual example of how and why this code is needed?

The whole point of the actual code, as is:

• The file, we thought that was needed to be uploaded, already exists online for some reason
• The hash + data size locally matches the online data

Why would the online file need to be replaced, when everything matches? The information only needs to be stored, thus negates a meaningless transfer.

[abraunegg]

@JC-comp
Specifically for this commit (38bc4a3), , do you have an actual example of hitting a 409 response when attempting a move - that required this code change?

I understand the edge use-case here, however, if something is already in the target location online, it most likely is already in the same location locally, so if you are moving the file|folder locally to an already existing location, the data is either going to be merged locally or replaced locally, thus is handled in the correct manner already to replace the content online.

[abraunegg]

@JC-comp
Additionally to the 2 comments above, as these 2 commits are 100% non-related, these should be separate PR items if they have the information to support their inclusion.

[JC-comp]

Both commits address issues related to cases where remote files are created at location A but are not reflected locally (either possible in local-first or monitor mode). Subsequently, uploading or moving files locally at/to location A can lead to inconsistencies (upload are not being handled and moves causing 409 conflicts).

commit 9426134 resolves upload problems when Integrity validation checks fail or are disabled.
commit 38bc4a3 resolves the issue of moving to a remotely created location by replacing it.

[abraunegg]

I do not think the updated logic here is correct.

If the response from fileDetailsFromOneDrive = checkFileOneDriveApiInstance.getPathDetailsByDriveId(parentItem.driveId, fileToUpload) generates a 200 we drop to the POSIX test.

In your code, you are then saving this data blindly to the DB, without validating that the details from online match what was intended to upload - so that DB save should not be happening until the validation of the data is done

Please can you review your thinking here

[JC-comp]

My idea was that if we maintain the latest online version in the local database, it can help force triggering a reupload
later during the database inconsistency check in case the corresponding upload process fail. Otherwise, there might be a risk of losing this inconsistency.

[abraunegg]

Closing in favour of #2595

[abraunegg]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.