MEGAsync
MEGAsync copied to clipboard
meganz
MEGAsync overwrites the file from the cloud when it is replaced with its earlier version
Steps to reproduce:
- Create a file in synced directory.
- Let the file to be synced.
- Change file modification date/time to some date in the past;
- (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)
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.
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.
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.
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.
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).
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.
- 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).
- 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.
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.
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.
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.
This explains why my files seem to be corrupting back! If it's by design I guess I need to stop using this.
Yep. It is by design. That's why I stopped using it.
El sáb., 25 may. 2019 0:15, lcsondes [email protected] 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 https://github.com/meganz/MEGAsync/issues/70?email_source=notifications&email_token=AA5G7KFFFPA7QDWDC4BQI7LPXBSHVA5CNFSM4DACZPH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGVOHQ#issuecomment-495802142, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5G7KB3WBZSPYEDMLPNLN3PXBSHVANCNFSM4DACZPHQ .
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.
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.
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.
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 went with storing self-encrypted blobs on OneDrive, no complaints about that one either.
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
About 4 and half years this has been open and nothing has changed. I don't think that they care.
This will be fixed, as part of a larger project, you can expect it within 6 months.
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?
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.
I stopped using MEGA primarily for this reason. Seems like it's not a priority.
I have the same issue. I have been trying to migrate my storage from one PC to another, but due to the difference in time zone between my zone and MEGA cloud, MegaSync is forcing an update from the Cloud! This is really stupid, and MEGA Cloud is too much of a risk to use. I have GIGABytes of traffic that I am forced to replicate from the web because of this bug! I need to find another cloud :( and too bad I was happy with the command line version and multi-OS support..
LOL, 5 years later and they haven't fixed such a serious problem. I can't believe this stupid thing is going to force me to look for another cloud service. 😒
I also encountered this issue some time ago (in a slightly different form). From my conversation with Mega support it seems that they believe the current behavior is correct (i.e. the file with latest "modified date" always overwrite other versions), and they suggest me to check the timestamp before syncing to avoid problems.
I also encountered this issue some time ago (in a slightly different form). From my conversation with Mega support it seems that they believe the current behavior is correct (i.e. the file with latest "modified date" always overwrite other versions), and they suggest me to check the timestamp before syncing to avoid problems.
It seems MEGA believes we should delete the file manually if we want to replace it with a local backup.
This makes MEGA unusable for me with my dual boot setup :/ I can't run the risk of just having my files go poof
I have just been caught out by this bug. Seems like it's still happening.
MegaSync failed to autostart on my desktop for some reason, before I made a bunch of changes in my KeepassXC db. I then moved to my laptop and tried to do something when I realised some of my recent changes weren't there. When I realised what happened, I closed KeepassXC on my laptop (making no changes) and started MegaSync on my desktop to allow it to sync, but it was too late. KeepassXC had changed the timestamp, so Mega wiped out all my changes. It's not impossible to fix, maybe 30mins work, but what if I hadn't noticed this? It could have been more serious. This bug is unforgivable.
MegaSync should maintain a local db of the files with their last modified time in ISO format and/or the file hash, such that timezones are irrelevant. When it detects a file has been changed in two locations, it should do the following:
- Add each variation to the previous versions in the file history, with an annotation that it's a conflicted version
- Create a new copy of each version as a new file, making it clear that it's a conflicted version via file naming
- Log the conflict
- Optionally (via config) show an error to the user
Any one of these options is better than the current behaviour, but a reputable application should aim for all four. The worst behaviour is what's currently happening; silently losing data.
