MegaSync re-uploads files from computer B after they have been deleted/moved/renamed on computer A about megasync

[RiseT]

@mattw-mega

I think you're talking about a case where the sync has not been disabled, unticked, deleted, recreated etc, just one machine has been off for a while, and is restarted which starts up MEGAsync with the sync still enabled.

Correct.

MEGA can't keep your actionpackets forever though so if it has been too long that process can't work and MEGAsync has to request the node tree again, and won't see the changes inbetween.

Ah, now we're talking. 3.5 years after I've opened this issue, I finally have confirmation what the culprit of it is. So thanks for the info.

1. As @thompson004 has mentioned, the current time frame of keeping the sync journal / action packets is far too short.
2. Independently of the question whether the time the sync journal entries are kept gets improved or not, please please please give users a warning (and the option to cancel) prior to requesting the node tree again in such cases, so that affected users can take cautionary measures before doing this. I've messed up that many previously organized folder structures due to this in the past, that I've completely stopped using MegaSync on more than one computer out of fear that lightning could strike again.

@thompson004
Thank you again.

[RiseT]

Quite frankly, I don't understand why 3 years after opening this issue, this serious problem still isn't fixed, while at the same time the client is getting other and less critical commits constantly.

[cmaziero]

Hi,

I'm having the same issue, in the opposite direction: sometimes I delete a local file and the MegaSync client downloads it back from the cloud. This happens quite frequently, sometimes more than once. This also happens when I move files or directories in the local machine, which results in having duplicated files everywhere.

My system is Ubuntu 16.04 - 64 bit, using Megasync client version 3.1.4 (0065d1).

In the logfile attached, the culprit files are memoria.txt and lcrandom.h.

MEGAsync.log

[hight0wer]

Hello, I'm facing a similar issue for a quite long time, not just in the last versions. I'm using SyncToy to make a copy of a Thurderbird profile to a folder C:\Email backup, which is synced by Megasync. There was a folder with about 2000 files in the folder extensions in the TB profile. I don't know the reason, but the folder is not there anymore (maybe after TB update). Now everytime I try to upload a new copy of the TB profile backup, Megasync downloads the 2000 files again. This happends on more than one computer. Everytime it's just one computer connected to each account.
I have launched Megasync in a debug mode and deleted the folder. After a while, Megasync downloaded all the files again. I'm sending you the log and also the folder, so you can try to reproduce the bug. Just put the folder inside some folders you're syncing and then delete it after the sync.
Hope this helps.

extensions.zip

[javiserrano]

Hello, we have been trying to reproduce the problem but we have been unable. For us Computer B always removes the local files after the step 4.

Are you using the same account in both computers? Or are you syncing a shared folder in one of them?

The usage of Cryptomator could be changing the scenario a bit. If those deletions are done in the virtual drive, the real files created by cryptomator could be doing something different and maybe that confuses MEGAsync. Or maybe cryptomator on Computer B doesn't like that MEGAsync deleted his files at runtime. Anyway, I'm just guessing.

MEGAsync should recognize the external deletion (or rename) and apply it in the local filesystem, except when the synchronization is added to MEGAsync. During the first scan, if MEGAsync detects missing files, it follows the most conservative approach and creates the missing files on the other side instead of deleting them. But once a synchronization is already added (it doesn't matter if MEGAsync is not running or is restarted) MEGAsync should correctly propagate the changes.

If you are able to reproduce the problem. Please create a debug log with Computer B while you are reproducing it. That way, we could see how the external notification is received, how it is managed by MEGAsync and why it doesn't apply it correctly.

To enable de debug mode, start MEGAsync with Ctrl+Shift pressed (Cmd+Shift on OS X), or open the settings dialog and click five times in the shield next to your email address. When the debug mode is correctly started, MEGAsync shows a notification that says that it is creating a log ("MEGAsync.log") in your desktop.

Once you have a log showing the problem, please send it to us to analyze it and fix the problem. If you don't want to share it here (it could contain sensitive data like filenames, etc.), please send it to [email protected] and post here the ticked ID so we can contact our support team to get your log. If you can provide additional information (like the name of the file that was incorrectly managed) that would speed up our investigation. Anyway, once you send your report to support, we could contact you directly by email to keep you updated and request additional information if needed.

Thank you very much!

This problem exists for me too. I'll try to describe it, since I have no option to log it at the moment. This has occured maaaaany times and it's starting to be annoying because we have more users to deal with at the moment. I can't keep up with keeping the drive organised this way.

• Computer A is Windows 8.1 x64
• Computer X is always a OS X variant
• Share a folder with another contact (not the same account) (= computer X)
• Both computers have MegaSync installed.

I can reproduce it very easily:

1. Take any number of files, sync/upload them onto your cloud drive
2. Make the share with the other contact, set it to read-only (he downloads the files)
3. Change the filename and location of a number of files (in windows explorer)
4. Set the share to 'full access' with the other contact (computer X)
5. Let the other contact set up the (shared) folder sync in the settings/SYNCS tab on his computer.
6. Witness files being downloaded that you renamed or moved earlier.

Note that having the share set to read-only, also means that it could very well be that Computer X is offline.
What happens for me very often is that when other Computers with the sync setup have been offline for a day or two, I changed file location, names or deleted some, and they don't receive the new state of these files.

My logical instinct says that there is something wrong with the way MegaSync handles filechanges. It scans for changes first, which happens before it checks if files have been renamed, moved or deleted by another user. Somewhere along the line this data of 'renaming/moving/deleting' gets stuck in the pipe and doesn't get sent through.

Clearing cache / emptying rubbish bin does not help. I tried on both occasions (with or without clearing it).

Good luck with reproducing this. I'll keep watch to help out.

[cmaziero]

Hi RiseT, I'm using it to sync 130 GB of files in 3 computers (all Ubuntu 16.04) these last 3 months and everything seems fine to now (crossing my fingers here...).

[Castigavi]

The issue occured on my end as well. It seems that if kit 1 removes the file while kit 2 is offline/has app turned off, then when kit 2 opens the app again, the removed files are uploaded again instead of being removed.

Repro steps:

1. Launch MEGASync on kit 1 and kit 2.
2. On kit 1 share a folder with files with kit 2 and let both kits sync.
3. Once done close MEGASync app on kit 1.
4. On kit 2 remove a file from the shared folder and ensure it is removed on the site as well.
5. Reopen MegaSync on kit 1. Observe how removed file is uploaded to the shared folder again.
6. On kit 2 observe how the removed file is downloaded again.

This makes it impossible to use MEGA for group projects, like modding communities etc which need a synchronised folder to upload their work. The issue above makes it impossible to remove not needed files, because it will always be uploaded again by another user that wasn't online at the moment of file deletion.

[thompson004]

A month or so IS a problem. I've tested it multiple times. The database should be kept for way longer than that, at least for a year, maybe longer for paying users. mattw-mega <[email protected]> schrieb am Do., 9. Jän. 2020, 21:32:

…

@RiseT <https://github.com/RiseT> I think you're talking about a case where the sync has not been disabled, unticked, deleted, recreated etc, just one machine has been off for a while, and is restarted which starts up MEGAsync with the sync still enabled. In that case MEGAsync will know about the deleted file because it will receive an actionpacket telling it about the file deletion, so that it can update its local cloud node tree cache, and that change is also processed by the sync code. MEGA can't keep your actionpackets forever though so if it has been too long that process can't work and MEGAsync has to request the node tree again, and won't see the changes inbetween. How long is too long? That varies but a month or two should not be a problem. cheers — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AK4FDASAFZQLACD6JYRHUYDQ46CUXA5CNFSM4CJBO47KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRVTQA#issuecomment-572742080>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4FDAX5UYYPQ262YWRLSQTQ46CUXANCNFSM4CJBO47A> .

[RiseT]

I'm still unable to produce this on purpose, but similiar to @hight0wer , I've been experiencing this once in a while since I've started using Mega 1 or 2 years ago.

I've used to think this only happens when I delete/rename a huge number of files, but yesterday, it happened when just moving a folder with a couple of files slightly deeper down the (sub-)folder structure (unfortunately, I hadn't activated logging at that moment). The result has been a duplicate of that folder. One at its original location (got re-downloaded at the moment MegaSync got started on a second computer) and one at the location I've moved the folder to.

I'll try to activate logging daily now and wait until the next occurence.

PS: Is there a way to activate logging permanently, i. e. logging still activated after a restart of MegaSync/reboot of OS? Otherwise it will be hard to log this since MegaSync on the second computer, which is incorrectly re-uploading the files deleted on the first computer, is autostarted with the OS and will start uploading instantly after scanning. So there's no time to activate logging. I suggest logging of a trailing time window of 24 hours (so anything older gets deleted).

[RiseT]

Just experienced this again recently with two Windows 10 machines (MegaSync v3.5). As this doesn't happen very often (but when it does, it can get ugly), it's pretty hard to enable logging at the right moment.

I've most often had this when one of the computers hadn't been online & thus synched for a couple of months.
If I had deleted (or moved or renamed) some files or folders on the "more up-to-date" machine, bringing online & synching the "outdated" machine happily recreates the deleted files/folders in the cloud (and creates duplicates if the files/folders had been moved/renamed rather than deleted) by uploading them from the outdated machine.

[hight0wer]

I've uploaded the log and files, which can be used for reproducing the bug, more than a year ago. I think it should help to find the problem, so you all don't need to bother with making another logs unless noone uses the informations we've provided..

New in this version:

• New UI style
• Support to generate file versions in MEGA
• Integration with Finder (macOS 10.10+)
• Allow to exclude specific files/folders
• Bug fixes and other minor improvements

srsly.

Can we put in a joint effort to try and reproduce this bug, and see if it still exists in the new version with the new 'file versions' addition?

[RiseT]

When I've downloaded the MegaSync client a couple of weeks ago, I got version 3.5 (with which I still experienced this issue). A couple of days ago, though, the MegaSync client updated itself. But the version number is still 3.5. I'm slightly confused about the difference of those two versions.

[cmaziero]

Things are worse here: after the last update (3.5, e16ed2), the client stays in a "scanning..." state forever, and syncs are not being done at all. I opened a ticket with Mega suport, let's wait.

[RiseT]

That's interesting. I have v3.5, f950d4, and the client says there's no additional update available. I wonder how many builds of v3.5 are floating around...

[cmaziero]

I believe the build number depends on the OS. Mine's is Linux Ubuntu 16.04 64bit.

[RiseT]

Ah, ok, makes sense. I'm speaking of the Windows client.

[aliulo]

I am using the sync app for Debian 9.0. I have just experienced the same issue, after 10 hours of making changes to one computer, the changes were reversed. Some logging in and out might have been involved ruing the changes were made, also, I had different versions of the sync client on both computers (one was 3.5, the other someting like 3.1.4 I guess.). Btw., is there any log of changes on the website, so that I can revert the automatic changes more easily?

[RiseT]

This is a nasty bug if it hits you, creating many hours of unnecessary work...

[RiseT]

v3,5.3 says "Improved the management of deleted files". Don't know if this is related to this issue as that version isn't on GitHub yet.

[noxecane]

Is there anyway to force megasync to use the local folder as reference. I am having the same issue as @cmaziero

[RiseT]

Has anyone tried this lately, i. e. has this been fixed? I'm hesitant to sync a second computer with my Mega cloud since it is so much work to clean up the mess this bug is creating when it hits.

[zukunfter]

I have a similar problem, quite annoying.

• I upload the photos automatically on my phone to Camera Uploads on Mega.
• I installed ubuntu on a computer.
• I copied all the files on a Mega folder from a backup in order to avoid downloading them again.
• All the files in the "Camera Uploads" folder on the computer are being re-uploaded and then they appear in Rubbish bin on Mega.
  All names of the folders match

[cmaziero]

zukunfter, this arrives frequently, because Megasync uses only times/dates and sizes to compare files: if two files are equal but have different dates, they will be synced. Synchronizations would be much more efficient if MS used hashes to compare files, to avoid re-syncing identical files. There is an open issue on this problem, with no answer yet: #181.

[cmaziero]

This nasty bug was not yet solved...

Yesterday I deleted/zipped hundreds of old files and directories in my home PC. Everything seemed ok. However, this morning the MegaSync client started and, after a quite long "analyzing files" pause, it re-downloaded most of the files I deleted yesterday, including entire directories that I zipped to take less place. :-(

I'm running MegaSync client version 3.6.7 (99a46c) on Linux Ubuntu 16.04.5 in two machines (at work & at home).

[RiseT]

@cmaziero Many thanks for this info. Will keep myself from synching another computer and mess up my data. I've done that too often now.

[thompson004]

I have the exact same problem, especially as described in OPs second comment in this thread.

It also happens to me, especially when I haven't used the second computer in a while.
It's really annoying because it means that you can't rely on the changes you've made. I will do a manual one-way sync on PCs I use infrequently from now on, it saves a lot of time compared to finding duplicates and files that should not be there.

I think it might have something to do with Mega discarding the database/file changes protocol, so after some time, it just treats the second PC as a sync that has been set up for the very first time.

[RiseT]

I think it might have something to do with Mega discarding the database/file changes protocol, so after some time, it just treats the second PC as a sync that has been set up for the very first time.

That's an interesting theory that is in line with my experience with MegaSync (i. e. it happens if I haven't used the second device for a while).

[dubluxas]

Same issue.

1. Downloaded file to d disk.
2. Extracted archive to same disk.
   Result:
   

[JaEdmuva]

Same problem between MacOS and Windows clients. For me, the Windows client re uploaded files that I previously deleted in the cloud and in the Mac folder. Files re appeared and lost all the clean up and organization work I did!

[seeyaayees]

Hello, i asume no one knows how to fix this yet.
i will now have to delete all of my cloud content and reupload from a correct device as it made a lot of wrong reuploads yesterday from a device i didn´t sync in a while and when i noticed it was to far gone..

it could have a way of just undoing any recent activity by mirroing one considered correct device.

[thompson004]

I too have to re-upload files when I turn on mega on devices I haven't used in a while. I already disabled the Autostart of Mega because of this and when I start it manually, I make sure I have an external hard drive connected to the (seldom used) device than I can mirror-sync the correct files from to avoid this issue. It's pretty annoying because the purpose of a sync service is partially to REMOVE the need of external devices to sync content. seeyaayees <[email protected]> schrieb am Mo., 21. Okt. 2019, 14:27:

…

Hello, i asume no one knows how to fix this yet. i will now have to delete all of my cloud content and reupload from a correct device as it made a lot of wrong reuploads yesterday from a device i didn´t sync in a while and when i noticed it was to far gone.. it could have a way of just undoing any recent activity by mirroing one considered correct device. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AK4FDAURZXP2APJHF4T3Y43QPWN4NA5CNFSM4CJBO47KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB2EQBY#issuecomment-544491527>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4FDATTIMJHAJWSIICRZDTQPWN4NANCNFSM4CJBO47A> .

[mattw-mega]

Hi seeyaayees and thompson004, your issue sounds like it could be due to the checkbox on the sync (in the settings page) being turned off and on again (either manually or due to an issue with the sync, such as permission problems (which would only turn it off)). When the sync checkbox is re-enabled, it starts from scratch comparing the local and remote state, as it has missed all the cloud changes in the meantime. So if a cloud file was deleted while the sync was off (unchecked), then when it's restarted it sees that the file exists locally but not in the cloud, and uploads it. Please let us know if that is the case for you.
Also, if you do upload a clean copy, if some or most of those files are already in your account somewhere, MEGAsync will recognise them by their fingerprint (a hash of the file data, size, and modification time), and clone the existing node instead of actually uploading the file, so the operation is much faster overall.

[thompson004]

Hello, thanks for your answer. I have never unchecked anything in the settings on any device as I'm happy with the default ones. mattw-mega <[email protected]> schrieb am Mo., 21. Okt. 2019, 22:34:

…

Hi seeyaayees and thompson004, your issue sounds like it could be due to the checkbox on the sync (in the settings page) being turned off and on again (either manually or due to an issue with the sync, such as permission problems (which would only turn it off)). When the sync checkbox is re-enabled, it starts from scratch comparing the local and remote state, as it has missed all the cloud changes in the meantime. So if a cloud file was deleted while the sync was off (unchecked), then when it's restarted it sees that the file exists locally but not in the cloud, and uploads it. Please let us know if that is the case for you. Also, if you do upload a clean copy, if some or most of those files are already in your account somewhere, MEGAsync will recognise them by their fingerprint (a hash of the file data, size, and modification time), and clone the existing node instead of actually uploading the file, so the operation is much faster overall. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AK4FDAXOBVXPYVYJBYHSATTQPYG6XA5CNFSM4CJBO47KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3WN7I#issuecomment-544696061>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4FDAWXX7QOMQL33GP2TETQPYG6XANCNFSM4CJBO47A> .

[RiseT]

@mattw-mega

When the sync checkbox is re-enabled, it starts from scratch comparing the local and remote state, as it has missed all the cloud changes in the meantime. So if a cloud file was deleted while the sync was off (unchecked), then when it's restarted it sees that the file exists locally but not in the cloud, and uploads it

I guess this issue comes down to the following questions:

1. If computer deletes file "xyz" locally, and this deletion gets synched with the cloud (i. e. the file gets removed from the cloud) while computer B is not running, how does afterwards computer B (after getting switched on & connected) know if a) the cloud with the missing file or b) its local folder with the file still present is the newest state?
2. As this issue mostly happens if computer B has been offline for a longer time: Is there any potential time constraint in the current solution for (1) - e. g. does it still work when connecting computer B after it has been offline for e. g. 6 months?

[thompson004]

Computer B knows that it shouldn't reupload the old file by looking at the sync database (which would show that the file has been deleted in the last sync). That's how it works even with Megasync in the first few days or even weeks in which Computer B hasn't been turned on, and how it works with sync programs like FreeFileSync for an infinite amount of time (which is why I use it to mitigate the Mega bug on seldom used PCs). Am Do., 9. Jan. 2020 um 12:08 Uhr schrieb RiseT <[email protected]>:

…

@mattw-mega <https://github.com/mattw-mega> When the sync checkbox is re-enabled, it starts from scratch comparing the local and remote state, as it has missed all the cloud changes in the meantime. So if a cloud file was deleted while the sync was off (unchecked), then when it's restarted it sees that the file exists locally but not in the cloud, and uploads it I guess this issue comes down to the following questions: 1. If computer deletes file "xyz" locally, and this deletion gets synched with the cloud (i. e. the file gets removed from the cloud) while computer B is not running, how does afterwards computer B (after getting switched on & connected) know if a) the cloud with the missing file or b) its local folder with the file still present is the newest state? 2. As this issue mostly happens if computer B has been offline for a longer time: Is there any potential time limitation in the current solution for (1) - e. g. does it still work when connecting computer B after being e. g. 6 months offline? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AK4FDASK2J5QVZA6MERDRALQ44AUFA5CNFSM4CJBO47KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIP5XII#issuecomment-572513185>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4FDASYAKATZ4T4N26KDJDQ44AUFANCNFSM4CJBO47A> .

[RiseT]

@thompson004 Thanks for the explanation (btw - where exactly is the sync database located?).

So this bug could be due to MegaSync's sync database only looking back a limited (vs. infinite) amount of time (or a limited amount of sync entries), right?

[mattw-mega]

@RiseT I think you're talking about a case where the sync has not been disabled, unticked, deleted, recreated etc, just one machine has been off for a while, and is restarted which starts up MEGAsync with the sync still enabled. In that case MEGAsync will know about the deleted file because it will receive an actionpacket telling it about the file deletion, so that it can update its local cloud node tree cache, and that change is also processed by the sync code. MEGA can't keep your actionpackets forever though so if it has been too long that process can't work and MEGAsync has to request the node tree again, and won't see the changes inbetween. How long is too long? That varies but a month or two should not be a problem. cheers

[thompson004]

@RiseT I think the database is located in the cloud and once a certain device has been inactive for a specific (and way too short) amount of time, Mega removes the device from its "Known devices", thus when this old device logs on to the account again, everything just gets merged together (local and cloud content). RiseT <[email protected]> schrieb am Do., 9. Jän. 2020, 12:30:

…

@thompson004 <https://github.com/thompson004> Thanks for the explanation (btw - where exactly is the sync database located?). So this bug could be due to MegaSync's sync database only looking back a limited (vs. infinite) amount of time (or a limited amount of sync entries), right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AK4FDAU5X75ZGATUTFTJFTLQ44DE5A5CNFSM4CJBO47KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIP7S5Y#issuecomment-572520823>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4FDAWOC7G3H73ZN3KKKZTQ44DE5ANCNFSM4CJBO47A> .

[peslun]

This bug is biting me everytime I return to my computer at my parent's house. I am happy that @RiseT found out where is this bug hiding.

What can I do to get rid of it? Open a ticket, give a upvote to a feature, something else?

[PauKokura]

Hi, I also have this issue with the two devices side by side and synced. It just doesn't matter if I delete a folder in computer A, computer B or even in mega.nz cloud. Also if I am moving a folder inside another, the first "instance" reappears, take it's space and consume my daily quote.

[mattw-mega]

Hi PauKokura, which devices, with which OS and which MEGAsync version are you using? If you could supply logs from both of this happening, we will look into it. Depending on platform, the location of the logs folder varies, but on windows it's at C:\Users<you>\AppData\Local\Mega Limited\MEGAsync\logs. Let us know the name of the thing you moved/deleted, where it was, etc, and critically: the time (preferably in GMT) so we can find it in both logs. thanks

[PauKokura]

MEGAsync for mac, updated to the last version (4.3.3 b2948c7)
A - Macbook Pro with Mojave 10.14.6
B - Imac with High Sierra 10.13.6
C - the Android app
If you could please indicate where the logs are stored in a mac. I don't find them. Thanks in advance.

[jonkerpeter]

I have the same problem, contacted MegaSync many times, but anything they say is incorrect. This is ourageously ridiculous. This problem exists for over 4 years and Mega doesn't even TRY to solve it. It could be so simple. Just create an option where you can turn off two way syncing (if you wish) and set one PC or the cloud as master. So extremely simple, but I guess not the smartest people work at Mega. I am so sorry I took a paid account and didn't find out about this before. In stead of making life easy it has changed into a horror scenario. If you do not use Mega yet: DON'T, look for another solution.

[Gambloide]

I just had the same problem after only ~a week of divergence between systems:

1. had a laptop with fully synced account
2. got the PC
3. installed MegaSync on new PC
4. logged in to the same account and it synced (mostly) fine
5. didn't use the laptop for a few days but moved, edited and deleted files on the new PC
6. started the laptop again with MegaSync set to start automatically
7. MegaSync began to upload all the files that were deleted again and also created duplicates of files which were moved

The support I received was unable to help in pinpointing the cause or help to provide instructions on how to prevent the issue occurring again.

Usually I would provide details on the involved systems, but from what I gather this problem lies with the server-side.

[Blatantist]

My issue takes place on just one Win 10 computer that's synced to the cloud:

I have a directory synced to Mega that I store photos on, with a folder structure similar to this:
C:\Photos -->
|         \Vacation
|         \Birds
|         \Family
|         \Unorganized -->
|         |            \SD Card 1
|         |            \SD Card 2

(I hope my representation of a file tree made sense.)

Today, I tried organizing some photos in my synced folder, and this happened:
The entire "Photos" folder is synced. Two days ago, I added all the photos from two SD cards to the corresponding folders on this computer. I moved a photo from an SD card to one of the organized folders, and the MegaSync client automatically redownloaded the file to the SD card folder after seeing that it was "missing." After I either move the file to the organized folder again (and select replace file in destination) or delete the file, it doesn't redownload it. This happens without fail, every time.

This only happens when I move files. If I just delete a file from an SD card folder, it isn't redownloaded. The problem also doesn't occur if I cut and paste files to the organized folders. I would just do that, but I have to actually open the destination folder to paste to it, which is slower than just dragging from the SD card to the destination folder's icon.

This is extremely annoying. I have no idea how the MegaSync client can't tell that a file is being moved, especially since I am moving files between two folders within one synced directory!

[SigmaTheFox]

Nearly 5 years later of this issue being open and it still hasn't been fixed... What a joke.

I gave a friend full access to a folder I regularly update, and when I delete a file on my PC, on her end it will still remain, then every couple of months her PC will decide to re-upload those files and delete a few I added.
I asked her if by any chance she has the PC off for a while, or if she maybe doesn't autostart MegaSync after reading through here, but she said she uses the PC daily and has autostart enabled.

We already tried everything, both of us reinstalled MegaSync, I removed and gave full access, both forced a sync, she even created a new account I shared the folder with. Nothing worked. Inactivity isn't the issue either because as I mentioned above she has MegaSync run daily. Only thing I can think of is, maybe because of her living in a completely different timezone, MegaSync gets confused about what files should and shouldn't exist.

[Blatantist]

I would guess that the root of the issue and why it hasn't been fixed is that MegaSync doesn't have the administrator privileges to hear from windows (or whatever OS you're using) if a file is being deleted or moved, but is only able to see if a file exists or doesn't, so just guesses if the file was deleted or went missing. The thing is, in cases where both computers (or in my case, my one computer) are on and have MegaSync running, there's no reason that a file would suddenly just go missing. Additionally, on my computer, it seems like MegaSync can tell the difference between a file going missing and being deleted. If that's true, there's no reason that this should still be a problem.

[jiping-s]

I have the same issue with Windows + OS/X. I never had problem with multiple Windows installations syncing the same folder, but OS/X reuploaded old files repeatedly even after I removed them from Windows.

[oxyopes]

Hi, just passing by to say that I have the same problem and also getting angry that MEGA does not solve it! Where are u guys???

[prismspecs]

I also have this issue. I believe the problem might be related to having a dual boot system (MEGA storage is separate and not shared though) in which Windows has a different timestamp than Linux. Because I am frequently moving between OS and machines I don't always fix this issue promptly, and this may lead to some sync errors, since an updated file from Linux will have a later timestamp than an old file on Windows when I switch over.

[Sadret]

Same issue here. 8 years have past and it is still not fixed :/