MEGAsync overwrites the file from the cloud when it is replaced with its earlier version

[ievgen-baida]

Steps to reproduce:

1. Create a file in synced directory.
2. Let the file to be synced.
3. Change file modification date/time to some date in the past;
4. (Alternatively) recover previous version of the file preserving its original date (in the past).

Result:

After file sync is finished, its date/time is reverted (i.e. synced from MEGA cloud).

Expected result:

File date/time is synced to MEGA cloud.

Environment:

Windows 10 (10.0.14393), 64-bit
MEGAsync 3.0.1 (bba5666)

[javiserrano]

Hello,

To achieve a totally deterministic behavior, MEGAsync always syncs the newest file (newer modification time) so if you have changed the modification time to the past, MEGAsync should download the file from the cloud (reverting your change), but if you changed the file to a newer timestamp, MEGAsync should upload it to the cloud. Otherwise, we would have a bug.

[ievgen-baida]

Hello,

While it makes some sense and greatly simplifies sync logic, having such limitation is a problem:

For example, you find that latest revision of the file contains unnecessary changes (corrupted, etc) and you decide to recover previous version from the backup or from the other cloud provider.

You will never have that file recovered (with the write/change date in the past) until MEGAsync app is terminated and the date is changes manually to a newer one.

[Gummar]

True, I've been worrying about this all the time, it is good to know what happens and I couldn't find this anywhere, a good solution would be local database about the md5 of each file (because the mega servers doesn't have md5 data stored, I think) and check whether the md5 of each file is different, after checking if the file sizes match, with those in database, maybe adding a mirror (upload only, no file download, override different files always) option for sync directories would be a good workaround, because I want to have a folder that is backup of program directories (with symbolic link) and I want to be sure they are perfect copies, not knowing if files with older timestamp are going to override newer ones makes me really worry.

[charlescanato]

This behavior definitely bombs reliability out of MEGAsync. I also just experienced this: copying back a configuration file just to see it magically returning to its previous and wrong state, although newer. I simply wanted to manually rollback a configuration file. Took me some time until I figured it was MEGAsync downloading the file back from the cloud, since that folder is the only Sync I have in the application.

If this is really by design, I can't see how this behavior is acceptable - it's the opposite of any other reliable sync software.

[GitStorageOne]

Windows has file history service. Which means that any file can be restored to earlier state.
Current behavior is definitely wrong.
Let users to decide how to solve collisions by showing info about rolled back files with question - what to do (per each file, as table).

[jjchico]

Replacing an existing file by another with the same name but older date/time is a common task. This issue may lead to very disappointing results. I do not know how it is done, but Dropbox handles it in the right way, even if Dropbox is not running at the time the file is replaced by the old one.

I am switching back to Dropbox because it is too much a risk for me.

A local database with "update" times of each file (maybe indexed by md5) may do the trick. "Update" time is last time megasync has processed the file, not the actual file's modification time.

1. If megasync is online, it should detect the file have changed and should upload the new version, even if the modification time of the new version is older than the update time in the database. Just for sanity, if the update time at the server differs from the local database, it is a conflict (the file have been modified by another megasync client).
2. If megasyng is not running, upon startup it should check all the files in the folder, and:
   2.1. If a local file has changed (based on md5) but the update time in the local database is the same or newer than in the server, the file has been modified locally and should be uploaded, no matter its modification time is older.
   2.2. If the local file has changed but the update time in the local database is older than in the server, there is new version in both ends and there is a conflict.
   2.3. If the local file has not changed, upload or download depending on local and remote update times.

Conflicts may be handled by creating a copy of the file (a la Dropbox):

• Conflicts in 1 should not happen since megasync is online, but if it does happen (maybe multiple clients syncing) the copied file should be the one in the server: it is the user who is changing the file in the client at the time of the check.
• Conflicts in 2.2: the copied file should be the older one, this time considering the modification time of the local file, not the update time in the database. There are two diverging version of the file modified in the past so it is better to stay with the newer one.

[audioscavenger]

Megasync HAS A BUG with time detection.
I have this problem and it messed up my homework assignments many times.
I have to constantly create new files named v2, v3 etc
it's very annoying.
The only way to circumvent this once it decides to overwrite a file, is to delete it and recreate it.

[EibrielInv]

This is an issue when someone send me a file from other timezone. I am unable to change the file until my clock catchup with the original modification time.

For example:

• I am in America, I gent a .zip file from Europe via email.
• I put the file on a sync folder and unzip it.
• I am unable to change the unzipped files for about 4 hours.

[metorm]

I have just triggered the same issue as @GitStorageOne. I had restored the file from Windows file history service, but the file is covered by the newer version a few seconds later.

[lcsondes]

This explains why my files seem to be corrupting back! If it's by design I guess I need to stop using this.

[jjchico]

Yep. It is by design. That's why I stopped using it. El sáb., 25 may. 2019 0:15, lcsondes <notifications@github.com> escribió:

…

This explains why my files seem to be corrupting back! If it's by design I guess I need to stop using this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=AA5G7KFFFPA7QDWDC4BQI7LPXBSHVA5CNFSM4DACZPH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGVOHQ#issuecomment-495802142>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5G7KB3WBZSPYEDMLPNLN3PXBSHVANCNFSM4DACZPHQ> .

[facundoq]

I'm sorry but THIS MAKES MEGA UNUSABLE. It makes me afraid of ever copying a file to a synced folder.

You just costed my an ENTIRE MORNING debugging some code because THE LAST THING I would expect is this GLARING BUG from a FILE SYNCING SOFTWARE.

I understand that using the file's last modified date simplifies keeping track of which files need to be synced, but THIS IS THE WORST POSSIBLE SOLUTION you could use.

Please DON'T OFFER A CLIENT if it's broken. This is not the expected behavior IN ANY PLATFORM, IN ANY APPLICATION. I don't care if it's free. This is like giving away free cyanide candy.

I think the last time I used so many caps in the internet was 20 years ago.

[halachkin]

Are there any updates?

[furioness]

Just got the same situation. Electricity turned off and I put an SSD drive from PC to notebook. I'm using the dual boot for Windows and Linux and had to fix something to have the time on both OS, so... eventually, when I put the drive back I get the bug - any new changes reverted back. If checking the file modified date, it would show some future time.

Thanks freaking god, I found the correct version in .derbis folder. though not in cloud file versions.

[glocalglocal]

This bug nearly drove me mad. I was using an application that batch compresses files of different types. It optionally retains the date of the original file, which of course make sense if you don't want to end up with 1000s of files with the same date. Mega quietly replaced the compressed files with the uncompressed ones. Now I am worried Mega may lose my data if I do the wrong thing without checking afterwards.

[rsalmei]

I'm not affiliated with Dropbox in any way, but I know they are the only company that does this right.
Sync is very hard, you can read more about it here.

[lcsondes]

I went with storing self-encrypted blobs on OneDrive, no complaints about that one either.

[GentlyD]

I'm not affiliated with Dropbox in any way, but I know they are the only company that does this right.
Sync is very hard, you can read more about it here.

I second that. Dropbox works like a charm (I am not affiliated either). The known problem is it is lacking encryption with keys only in your possession and with added 3rd party encryption seamless sync becomes a challenge. I had enough of these MEGA sync issues lately and quit. Now working with a combination of NAS and Sync.com

[Perkolator]

About 4 and half years this has been open and nothing has changed. I don't think that they care.

[mattw-mega]

This will be fixed, as part of a larger project, you can expect it within 6 months.

[tmargary]

This will be fixed, as part of a larger project, you can expect it within 6 months.

@mattw-mega Thanks for the update. Any news about the fix?

[AbstractXavier61]

I'm pretty sure most people using this is having the same problem, I started having this yesterday which is annoying as hell, and it keeps overwriting the new stuff I want to replace the original, but it keeps coming back.

[tmargary]

I stopped using MEGA primarily for this reason. Seems like it's not a priority.