After problems caused by (Bug Fix #3344), further duplicates and file/directory name changes uploaded to cloud with (1) suffix appended.

[aidyw]

After reporting a potential bug #3393 I have yet to replace the onedrive code with the master branch build. However I was hoping to understand if it 100% certain that the issues caused by bug #3344 are also responsible for the many files that where uploaded to onedrive in the cloud.
There seemed to be little correlation between failed downloads and the many (over 60) files that where either renamed with (1) suffix or that had duplicates add with the (1) suffix.

I am aware that this suffix addition is the default behavior of the os to deal with copies created with the same name but I have no idea why the client did this and why some caused duplicates while other fully replaced the files.

This was a painful mess to resolve. I had to one by one resolve the re-naming issue and individually check if the renamed versions where actually the most recent files.

Was this some kind of interaction of the local file system trying to deal with copies that the onedrive client then dutifully tried to synchronise?

It also did this with directory names and not just files. Why and how could this have happened as I never changed the names of or deleted any directories before this failure occurred.

[abraunegg]

@aidyw
The 'Client returns an error about local file system : No such file or directory then deletes the file from OneDrive even though it has not successfully synced' (your #3393 issue) is 100% caused by bug #3344 and has been fixed.

There seemed to be little correlation between failed downloads and the many (over 60) files that where either renamed with (1) suffix or that had duplicates add with the (1) suffix.

This client does not add any suffix of (1) or similar to any file.

The older 'skilion' client may be responsible for that - I cant recall.

This client performs 'safe rename' operations as per https://github.com/abraunegg/onedrive/blob/master/docs/client-architecture.md#file-conflict-handling---default-operational-modes

v2.5.2 and below:

file5-onedrive-client-dev-2.data

in v2.5.3 and above:

file5-onedrive-client-dev-safeBackup-0001.data

This client has never used a suffix of (1) for any rename operation.

It also did this with directory names and not just files. Why and how could this have happened as I never changed the names of or deleted any directories before this failure occurred.

Potentially you have something odd going on with your system.

Your log files show zero events of this application performing any 'rename' to a suffix of (1) or any other numerical value.

If you are 100% convinced that this client is at fault, please do the following:

1. Remove the OpenSuSE Package
2. Build the client from 'master' and ensure you are running onedrive v2.5.6-38-g4301c2e or greater on your system
3. Ensure you have logging enabled, and use --verbose at a minimum to capture any rename event (which should be verbose at least) where that rename is using a (N) character designation

The code that performs the safeBackup routine starts here:

onedrive/src/util.d

Line 58 in 4301c2e

void safeBackup(const(char)[] path, bool dryRun, bool bypassDataPreservation, out string renamedPath) {

[aidyw]

I never had the Skillion client on any machine, but thanks for the clarification. I am very used to seeing the 'safeBackup' files. they seem to appear regularly and I am convinced they are an artifact of the bug that hopefully my compiling from source will resolve.

I will try it from source later after I'm finished for the day with work.

I suspect that as you say the (1) suffixes have been added by the file system at some point when somehow the client has attempted to copy over files and directories.

That being said, I can assure you that no other file system interactions took place manually between the dubious sync from my desktop machine, during which the bug deleted my files from the cloud. I first noticed that these files had been deleted after I synced onto my laptop and these files disappeared from the laptop; therefore I then recovered manually the files from the cloud recycle bin, and after doing this I ran the client again on the laptop, which successfully replaced the recovered files named correctly on the laptop. I then shutdown the laptop and started again my desktop, attempted to sync the onedrive client and then all these (1) suffixed files where moved into the cloud.

You can clearly see the process taking place in the logs that I attached this morning to case #3393.

Please allow me to thankyou for all the hard work you have done in creating and maintaining this client. For the most part it has proved invaluable and even with these issues it has been very useful.

However, I really don't want this to get any worse. This morning I lost over 3 hours correcting the mess that resulted. I only wish to get to the bottom of all this. In fact I am replicating a git repo that I have stored on onedrive. I realise that this is probably not ideal, but it is how it is internally with my work situation.

If I corrupt the contents of this I will have a world of pain on my hands.

Thanks for your suggestions.